Server Quality Checklist

Tool Scores

• analyze_async_bottlenecksA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• analyze_call_tree_pathA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• analyze_gc_pressureA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• correlate_source_codeA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• diff_profilesA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• extract_hottest_functionsA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.