Server Quality Checklist

Tool Scores

• get_largest_routesA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full behavioral burden. It communicates that this is a ranking/read operation on loaded build data and that it focuses on emitted chunk bytes, but it does not explicitly state read-only behavior, output shape, sorting direction, or error conditions. This is adequate but not rich.

  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?

  One sentence with no filler; the key scoping qualifiers ('loaded Next.js build', 'user-facing routes', 'emitted chunk bytes') are all included. It is efficiently front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-ranked listing, the description plus a 100%-covered schema is nearly enough. Yet with no output schema and no annotations, the agent lacks explicit guidance on the result format or when to choose this tool over siblings like get_shared_chunks, leaving a small but real 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?

  All parameters are fully described in the schema (100% coverage), so the description need not add much. It adds no new parameter-level meaning beyond the schema; the schema already explains limit defaults and buildId provenance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the action (rank), the object (heaviest user-facing routes in a Next.js build), and the criterion (emitted chunk bytes). It does not explicitly distinguish itself from siblings like compare_builds, but the specific resource and measurement make the function unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool operates on an already-loaded build, and the schema's buildId note ('Build ID returned from load_build_stats. Omit to list loaded builds') hints at the workflow. However, the description itself gives no explicit when-to-use guidance or exclusions relative to the sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• load_build_statsA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the disclosure burden. 'Parse' and 'load' weakly imply a read-and-ingest operation with no file modifications, which is useful but not explicitly stated. The description does not mention side effects, session state, failure conditions, or whether any prior data is overwritten.

  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 a single well-structured sentence. It front-loads the action ('Parse a Next.js .next directory'), then states what is loaded and for what purpose, with no filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description explains the high-level purpose and what data is made available, but with no output schema and no annotations it leaves some gaps: the exact shape of the loaded data, whether it is stored in memory, and whether a prior build is required are not mentioned. It is adequate for a simple loader but not comprehensive.

  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 input schema already fully documents both parameters. The tool description itself adds no additional meaning about buildDir or buildOutputPath beyond what is already present in the schema, matching the baseline of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Parse ... and load') and names a concrete resource (the Next.js .next directory) and data type (route and chunk footprint data). It distinguishes itself from analysis siblings by mentioning 'for later analysis,' but it does not explicitly differentiate itself from load_webpack_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'For later analysis' implies this tool is a first step before calling analysis tools like get_largest_routes or compare_builds. However, there is no explicit statement of when to use this tool versus alternatives, no exclusions, and no mention of prerequisites such as needing a completed Next.js build.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• find_duplicatesA
  3.6/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the behavioral burden. It usefully discloses that results are ranked by wasted bytes and that a prior webpack stats load is required. However, it does not mention the output shape, whether the operation is read-only, or failure/edge-case behavior.

  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 short sentences, front-loaded with the main purpose and ranking behavior, followed by the key prerequisite. Every word earns its place and there is no redundant 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?

  For a relatively simple analysis tool with two well-documented parameters, the description covers the core purpose, ranking behavior, and prerequisite. It is not fully complete because it ignores the overlapping sibling tools and provides no output format guidance, but it is sufficient for basic 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 description coverage is 100%, so buildId and limit are already documented in the input schema. The description does not add parameter-level meaning beyond the schema, which is acceptable under the high-coverage baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the resource (npm packages bundled into multiple chunks) and the action (find), with a specific ranking criterion (wasted bytes). It is not tautological and conveys a useful mental model, but it does not explicitly differentiate from overlapping siblings like get_shared_chunks or explain_shared_chunks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear prerequisite: 'Requires load_webpack_stats first.' However, it does not explain when to choose this tool over get_shared_chunks or other related siblings, nor does it mention when not to use it. This gives partial context but leaves selection logic to the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• compare_buildsA
  3.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden for behavioral disclosure, but it only describes the happy-path comparison. It fails to mention that omitting both build IDs lists loaded builds instead of comparing, and it says nothing about error behavior or reliance on load_build_stats. This is a notable transparency gap for a tool with a dual mode.

  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?

  A single, front-loaded sentence states the action, subject, and result with no filler. It is appropriately concise for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  There is no output schema, and the description only vaguely indicates the output ('which routes and chunks grew or shrank the most'). It omits the fallback behavior of listing loaded builds when IDs are omitted, which is important for correct invocation. Still, the primary use case is clear enough for an agent to attempt a correct call.

  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 broad context about comparing routes and chunks but does not clarify parameter meaning beyond the schema, such as how limit applies or which build IDs to use.

  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 ('Compare') with a clear resource ('two loaded Next.js builds') and a concrete outcome ('show which routes and chunks grew or shrank the most'). This clearly differentiates it from siblings like get_largest_routes, which analyze a single build, and load_build_stats, which loads builds.

  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 clearly implies when to use this tool: when the user wants to compare two builds that have already been loaded. However, it does not explicitly mention alternatives or exclusion conditions, such as using get_largest_routes for a single build or explain_growth for understanding why growth occurred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• explain_growthA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full transparency burden. It discloses that the tool operates on already loaded builds, performs an analytical rather than mutating task, and returns a structured set of findings and summary. It does not explicitly discuss side effects or prerequisites beyond loaded builds, but the verbs and return list make the behavior clear.

  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 purpose-dense sentences contain every necessary element: the scope, the analytic target, and the returned output. There is no filler, no repetition of schema details, and the core intent is front-loaded.

  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?

  For a tool with no output schema, the description adequately names the main return categories and the precondition of two loaded builds. It does not explain ranking methodology or explicitly route around overlapping siblings, but parameter mechanics are fully covered by the schema, making the overall description sufficient.

  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?

  All three parameters have complete schema descriptions, including the omit-to-list behavior for build IDs. The tool description adds context about the overall analysis but no parameter-level meaning beyond the schema, so the baseline score 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?

  States a specific analytical verb ('Identify') and resource ('routes and chunks') plus the exact condition ('bundle size growth between two loaded builds'). The mention of severity-ranked route findings, top growing chunks, and a regression summary distinguishes it from general comparison siblings like compare_builds.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies a two-build comparison scenario, but it never explicitly states when to choose explain_growth over siblings such as compare_builds or explain_shared_chunks. There are no exclusions or alternative routing cues beyond what the name and scope suggest.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_shared_chunksA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the disclosure burden, and it clearly states the core behavior: ranking shared chunks and showing dependent routes. It would benefit from mentioning the no-buildId listing mode, but the primary behavioral contract is transparent and non-mutating.

  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?

  A single sentence conveys action, scope, and expected result with no redundant phrasing. The key verb and object are front-loaded, making the tool's purpose immediately clear.

  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?

  For a tool with two optional parameters and no output schema, the description plus schema covers how to invoke it: it names the prerequisite state, the result shape, and both parameters. A small gap is that the description's 'loaded build' framing does not acknowledge the omit-buildId mode, but the schema fills this in.

  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 both limit and buildId already have meaningful descriptions in the schema. The description adds no parameter-specific information, so the baseline score 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 opens with a specific action ('Rank'), targets a concrete resource ('heaviest shared chunks'), and states the derived output ('show which routes depend on them'). This is distinct from sibling tools like get_largest_routes, which targets routes rather than chunks, and explain_shared_chunks, which is about explanation rather than ranking.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in a loaded Next.js build' implies that load_build_stats should be run first, which is useful context. However, the description never explicitly says when to choose this tool over explain_shared_chunks, get_largest_routes, or suggest_optimizations, and it leaves the omit-buildId behavior to the schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• load_webpack_statsA
  4/5.0
  Behavior3/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 reveals that the tool is stateful by linking to a build loaded with load_build_stats and that it unlocks other tools. However, it does not mention failure modes, idempotence, or what happens if the build is not available, leaving some behavioral gaps.

  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 sentences deliver the core action, the prerequisite, and the downstream impact with no filler. The information is front-loaded and every clause 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?

  For a one-parameter loader with no output schema, the description covers what the tool does, how it connects to the build lifecycle, and which tools become available afterward. It does not describe the return value, but that omission is minor given the tool's enabling role and clear input contract.

  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% and the single buildId parameter has a clear description: it is returned by load_build_stats and determines the stats.json directory. The tool description adds workflow context but no additional parameter-level meaning, so the 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 names a specific verb and resource: parsing the webpack module stats file and linking it to an already-loaded build. It also distinguishes the tool from siblings by listing exactly which stats-powered tools it unlocks, making its role in the workflow clear.

  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 clearly states the prerequisite of calling load_build_stats first and identifies when this tool is needed by naming the downstream tools it enables. It does not explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to route correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• trace_importA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It adds a valuable interpretive detail ('moduleSizeBytes is the unminified webpack module size, not emitted chunk size') and a prerequisite. It does not explicitly state read-only behavior or return shape, but 'trace' and 'explain' imply a non-mutating operation.

  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 sentences with no filler. Purpose, output semantics, and prerequisites are all front-loaded and each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, a prerequisite, and one output caveat, but it does not describe the trace result structure despite having no output schema. There is also a slight workflow ambiguity: the schema ties buildId to load_build_stats while the description only mentions loading webpack stats first.

  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 applies. The schema already documents buildId, moduleName, and limit; the description does not add parameter-level detail beyond the schema. The moduleSizeBytes note is about output interpretation, not input parameters.

  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 action ('Explain why a module is bundled') and a specific method ('tracing its import chain from an entry point to the module'). This clearly distinguishes the tool from sibling tools focused on chunks, duplicates, or growth.

  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 use case is clearly framed: use it to explain why a particular module is bundled. It also gives a prerequisite ('Requires load_webpack_stats first'), which helps an agent sequence its calls. It does not explicitly name alternative tools or exclusions, but the context is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• explain_shared_chunksA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even with no annotations, the description conveys that this is a read-only analysis tool through 'Show' and 'reports'. It also discloses the exact computation applied to each package's size metrics and the need for prior data-loading calls. It does not mention error behavior or explicit side-effect absence, but the read-only framing is strong.

  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 compact and front-loaded: the purpose appears first, followed by output metric details, then the prerequisite. Each sentence earns its place, with no fluff or repetition of schema content.

  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?

  For a tool with no output schema, the description adequately defines what each result reports and names the required prior steps. It does not fully describe result ordering or response shape, but the core invocation needs and output expectations are covered.

  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 schema already documents buildId and limit, including the default and maximum for limit. The description does not add extra meaning for these parameters, which matches the baseline of 3 for fully covered schemas.

  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 ('Show') and a precise resource ('which npm packages and app code dominate the shared chunks loaded by many routes'). It clearly states the analytical goal, identifying what bloats common bundles, which distinguishes it from sibling tools like get_shared_chunks.

  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 clear context: use this to attribute shared-chunk bloat to packages and app code. It also states the prerequisite ('Requires load_build_stats and load_webpack_stats first'), which is important invocation guidance. It does not explicitly name alternatives or when-not-to-use conditions, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• suggest_optimizationsA
  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 behavioral burden and does well: it discloses that every suggestion is sized in emitted on-disk bytes, that ranking is by severity, and that suggestions are evidence-backed. It also reveals the dependency on webpack stats for certain suggestion categories, which is non-obvious but important behavior.

  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 with high information density and no filler. The core behavior and output value are front-loaded, and the important prerequisite about load_webpack_stats appears at the end without burying the main point.

  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 no output schema and no annotations, the description explains what the tool returns (suggestions), how they are ranked, how they are sized, and what data is required. It does not detail the exact suggestion schema, but for an agent selecting and invoking the tool, the workflow caveat and output gist are sufficient.

  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; buildId and limit are already documented in the schema. The description adds no parameter-specific semantics beyond the general workflow context, so it neither improves nor harms understanding of the inputs.

  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, 'Aggregate,' and names the resource domain: route, chunk, and webpack-stats evidence, producing 'bundle optimizations' with concrete Next.js actions. It clearly distinguishes itself from siblings by framing output as severity-ranked, evidence-backed suggestions rather than raw stats or duplicate lists.

  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 sequencing guidance: 'load_webpack_stats first for dedupe, shared-chunk, and package-import suggestions,' and clarifies that it 'works on manifests alone' as a lower-fidelity baseline. It does not enumerate when to choose sibling tools instead, but the prerequisite instruction is strong context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• how_to_collect_statsA
  4.3/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 explaining behavior. It makes clear that the tool returns either a self-applied recipe or an action plan for Copilot to execute, which is the core behavioral distinction. It does not explicitly state that the tool itself does not modify anything, but its instructional nature is reasonably evident.

  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 sentences, front-loaded with the primary purpose, and every clause earns its place. The choice between manual and automatic is stated immediately and economically.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple instructional tool with no output schema, the description is complete: it states what the tool produces, the two modes, and why it matters (required by bundle attribution tools). No critical information for calling it correctly is missing.

  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 useful meaning for the 'method' parameter by defining manual and automatic modes, but it does not add anything about 'scenario' beyond the schema. The description does not need to compensate heavily because the schema already documents both parameters.

  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 ('Explain how to generate') and a concrete resource ('.next/stats.json'), and it explicitly relates the tool to the bundle attribution tool family. It is clearly distinguished from siblings that analyze or load stats rather than explain how to collect them.

  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 clear context: this tool is the prerequisite for the bundle attribution tools, and it explains the manual versus automatic modes. It does not explicitly state when not to use it or name an alternative tool, but the context is strong enough for most agent routing decisions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.