Server Quality Checklist

Tool Scores

• ng_template_diagnosticsC
  2.9/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 adds valuable caveats about the empty list meaning 'no errors' only when the server is healthy and hints at output structure via 'entry anchored in the companion file'. However, it does not explain side effects, required permissions, or error conditions beyond server health.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness2/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short but poorly written. Phrases like 'files checks a batch' are ungrammatical, and 'An entry anchored in the companion file names it in file' is cryptic and adds confusion rather than clarity. The useful 'server healthy' caveat is buried in an unclear sentence.

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

  Completeness2/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 is insufficient to fully understand the tool's behavior. It lacks details on the response format, error listing structure, or what happens when both 'file' and 'files' are omitted. The tool is a diagnostic tool with moderate complexity, but the description does not adequately cover it.

  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?

  The description supplements the schema by stating accepted file extensions (.html or .ts) and that 'files' handles batch checks. Since schema coverage is 100%, this extra context is helpful but not extensive; it does not clarify parameter precedence or batch limits.

  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 opening phrase 'Angular compiler errors for a template after an edit' clearly indicates the tool reports compiler diagnostics for templates. This differentiates it from sibling tools like ng_component_info or ng_find_usages, though the rest of the description is grammatically confusing.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives is provided. The phrase 'after an edit' implies a context, but there is no mention of when not to use it or how it compares to sibling tools.

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

• ng_version_rulesB
  3.2/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. It only adds that 'Every rule was measured on the v17-v22 stand', which hints at reliability but does not clarify core behaviors: whether the tool is read-only, how it analyzes the project, or what happens for versions outside v17-v22. No mention of side effects, required permissions, 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, with two sentences and no fluff. The first sentence front-loads the core purpose. The second sentence, however, uses the vague phrase 'measured on the v17-v22 stand', which may confuse readers; it earns a minor penalty for clarity while remaining concise overall.

  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, so the description should help infer why the result is useful. The text gives a general sense of what the tool reports (existence/non-existence of features) but does not specify the format or granularity of the answer. For a simple query tool with optional parameters, this is minimally complete but not fully transparent.

  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 parameters are fully documented in the input schema. The description enriches the topic parameter by listing examples (template syntax, signals, DI) but not all enum values (components, control-flow, forms, testing). It does not add details about the path parameter beyond the schema. Thus it meets the baseline but does not significantly exceed it.

  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 (the project's Angular version) and the general purpose ('what exists and what does not') while naming specific areas (template syntax, signal APIs, zoneless, DI). This distinguishes it from sibling tools that focus on component info, templates, diagnostics, workspace mapping, or usage finding. However, it lacks a strong imperative verb like 'list' or 'check', making it slightly less crisp than an ideal purpose statement.

  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 usage when one needs to know whether an Angular feature is available in the project's version, but it does not explicitly state when to use this tool instead of alternatives. It also does not mention exclusions or complementary tools. Since the need is inferable from the phrasing, it earns a midpoint score.

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

• ng_find_usagesA
  3.5/5.0
  Behavior2/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 disclosing behavioral traits. It states what the tool searches for and that it accepts a file path or selector, but it does not disclose whether the operation is read-only, how results are returned, whether it follows workspace boundaries, or any performance or permission implications. For a search tool, the lack of a clear read-only guarantee or output format disclosure is a notable gap.

  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 that front-loads the core function before listing supported types and input formats. Every clause adds useful information, with no filler, redundancy, or unnecessary detail.

  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 effectively covers the tool's purpose and input format, which is essential. However, because there is no output schema, the description should ideally explain what a usage result looks like (e.g., file locations, line numbers, snippets). This information is absent, leaving the agent to guess the return structure. The presence of configurable parameters like limit and input adds behavioral nuance not explained in the description.

  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 schema already documents all four parameters. The description adds only a high-level summary ('Accepts a file path or a selector') that mirrors selectorOrFile's schema description. It provides no additional meaning beyond the schema, so the score stays at the baseline.

  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 function: finding usages of components, directives, pipes, or services across the workspace. It names specific resource types and explicitly mentions the two input forms (file path or selector), making both the action and scope unmistakable. This distinguishes it from sibling tools that address other Angular concerns.

  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 intended use — when you need to locate usages of a symbol — and states the accepted input formats. However, it does not explicitly contrast this with sibling tools like ng_component_info or ng_template_definition, nor does it mention when not to use it. There is no alternative guidance beyond the obvious purpose.

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

• ng_workspace_mapA
  3.8/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. It explains that the tool understands multiple workspace configurations and lists the information it provides, but it does not disclose return format, side effects, or why it should only be called once per session. The 'Call once per session' hint implies caching or heaviness, but lacks detail.

  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 concise sentences with no fluff. The first sentence lists the core content, the second adds context about config styles and usage frequency. All information is relevant and 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?

  The tool has no output schema, but the description enumerates the main data categories (projects, versions, strictTemplates, zone.js) and config styles. For a read-only mapping tool with a single optional parameter, this adequately sets expectations. It could benefit from stating return shape, but the sibling tools make the use case clear.

  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% (the single optional path parameter is fully described). The description adds no parameter-specific information, so baseline 3 is appropriate. The path meaning is already clear from the schema.

  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 states what the tool provides: workspace projects, versions, strictTemplates, and zone.js per project. It doesn't use an explicit verb like 'lists' or 'returns', but the noun-phrase structure conveys the resource and scope. It implicitly distinguishes from sibling tools by focusing on workspace-level overview rather than component/template specifics.

  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 instruction 'Call once per session' provides explicit usage guidance. Mentioning that it understands angular.json, Nx, and solution style indicates when it is applicable. It does not explicitly state when not to use or name alternatives, but the guidance is sufficient for this simple tool.

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

• ng_template_definitionA
  3.9/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 useful context about 0-based line/character coordinates and support for .html or inline .ts templates, but it does not disclose what happens when no declaration is found, the return format, or any error behavior. This is a moderate gap for a tool with no annotations.

  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, front-loaded sentence with no wasted words. It efficiently communicates the core transformation and coordinate convention without extraneous information.

  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 tool is relatively simple, but the absence of an output schema means the description should explain what the caller receives (e.g., declaration location, range, or null). It also doesn't mention edge cases like invalid positions or unresolved symbols. Given these gaps and the existence of sibling tools, the description is not fully complete, though it covers the essential purpose and input semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is low (33% — only 'file' has a description). The description compensates by clarifying the 0-based LSP-compatible semantics of line and character, and by specifying valid file types (.html or .ts with inline template). This adds meaningful value beyond the schema, though the description doesn't detail file path formats.

  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 function: mapping a position in Angular template files (.html or inline .ts) to its TypeScript declaration. This specific verb-resource pairing distinguishes it from sibling tools like ng_find_usages (usages) and ng_template_diagnostics (diagnostics).

  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 usage through the title 'declaration of a template symbol' and by describing the input position, but it does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. Usage guidance is understood but not stated.

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

• ng_component_infoA
  4/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 burden of behavioral disclosure. It explicitly states 'Reads the source' indicating a read-only operation, and 'ngserver is not needed' describing a key dependency trait. This is valuable context beyond the schema, though it stops short of detailing error handling or return 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, front-loaded with the core purpose. The first sentence lists what the contract includes, and the second covers accepted inputs and a key behavioral note. Every sentence contributes value with no unnecessary detail.

  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 single-parameter tool with no output schema, the description adequately covers purpose, input types, and a key behavioral trait (ngserver not needed). It is complete enough for an agent to understand what the tool does and when to invoke it, though it omits potential edge cases like file-not-found behavior.

  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?

  The schema already fully describes the only parameter 'file' with 'Path to the component (.ts) or to its template (.html)', giving 100% coverage. The description repeats this by saying 'Accepts .ts or .html', adding little new meaning. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 provides the public contract of a component or directive, listing specific elements (inputs, outputs, class members, decorator metadata). This distinguishes it from sibling tools like ng_template_definition and ng_find_usages, making its purpose 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 gives useful context: it accepts .ts or .html files and reads source without needing ngserver. However, it does not explicitly state when to choose this tool over alternatives or provide exclusion criteria, so the guidance is implied rather than explicit.

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