Loading ToolBench
MCP server for loading and analyzing V8 and Chrome CPU profiles for GitHub Copilot and other MCP clients
Strong tool definitions with consistent naming, good descriptions, and comprehensive schemas. All 9 tools follow verb_noun naming convention and have detailed descriptions (135-250 chars average, well within 10-1024 range). Input schemas are explicit with proper types, descriptions, and constraints. However, output schemas are not documented in the provided code, forcing LLMs to infer response structure. Error handling guidance is minimal, tools do not document recovery paths or categorize failures. Security is adequate (no secrets in params, read-only risk classification), but composition could be tighter (some tools could be combined or offer batch variants).
Compare two loaded CPU profiles side-by-side. Shows functions that got slower/faster and new/removed hotspots.
Returns detailed timing info for a specific function: self-time, total-time, callers, and callees. Use this to understand why a function is slow.
Returns the top N functions by self-time (CPU time spent directly in the function, not its callees). Use this to find performance bottlenecks.
Aggregate CPU self-time by npm package. Identifies which third-party dependencies are consuming the most CPU, by parsing node_modules paths from the profile. Useful for deciding which packages to replace, lazy-load, or avoid. Scoped packages (e.g. @babel/core) are handled correctly.
Returns an overview of a loaded profile: duration, sample count, top-level call tree (filtered to functions >0.1% of total time), and idle time percentage. For large profiles, the call tree is limited to depth 2 and top 20 children per node to keep output manageable. Also lists all loaded profiles if no ID is given.
Output schemas not documented. LLMs cannot infer response structure (field names, types, nesting). Forces agents to guess what fields to expect and how to chain tools together.
Error handling lacks recovery guidance. Tools do not document what errors are retryable, user-fixable, or fatal. No examples of invalid input validation messages (e.g., what happens if profileId does not exist).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
Returns a ready-to-run command and step-by-step recipe for capturing a V8 CPU profile, then loading it with load_profile. Use this when you do not yet have a .cpuprofile file. Choose the scenario that matches how the code runs.
Parse and load a V8/Chrome CPU profile from disk. Supports both .cpuprofile files and Chrome DevTools Trace JSON exports. Returns a profile ID for use with other tools.
Extract source code and per-line tick counts for a function. Shows which specific lines are hottest.
Identify the hottest functions in a profile and suggest pattern-based fixes ranked by expected impact.
Tool descriptions could explicitly state when to use each tool vs. similar ones. 'explain_function' vs 'read_source_context' distinction is unclear from descriptions alone, both return function details with source context.
No batch variants offered. Agents calling tools in loops (e.g., explain_function for multiple hot functions) waste tokens and latency. Consider offering explain_functions (plural) accepting an array of function names.
how_to_collect scenario parameter enum is underdocumented. Only two values ('next-server', 'script') are listed, but description conflates 'Next.js production server' with 'standalone server.js', unclear if these are mutually exclusive or ordered alternatives.