Server Quality Checklist

Tool Scores

• ng_addC
  2.9/5.0
  Behavior2/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 of behavioral disclosure. It states the tool runs 'ng add' to add a package, implying a mutation operation that modifies the Angular workspace. However, it doesn't disclose critical behavioral traits such as whether it requires specific permissions, what side effects occur (e.g., changes to configuration files), error handling, or any rate limits. This is a significant gap for a mutation tool with zero annotation coverage.

  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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose without any unnecessary words. Every part of the sentence earns its place by clearly conveying the action and target, making it efficient and easy to understand at a glance.

  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 the complexity of a mutation tool that modifies an Angular workspace, the description is incomplete. No annotations are provided to cover safety or behavioral aspects, and there's no output schema to explain return values. The description lacks details on what happens after execution (e.g., success indicators, error messages), making it inadequate for the tool's context despite the concise purpose statement.

  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 input schema has 100% description coverage, providing clear documentation for all parameters ('package', 'appRoot', 'options'). The description adds no additional meaning beyond what the schema already specifies, as it doesn't elaborate on parameter usage, examples, or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 the tool's purpose: 'Run 'ng add' to add a package to the Angular workspace.' It specifies the verb ('add') and resource ('package to the Angular workspace'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'ng_update' (which might update packages) or 'ng_generate' (which creates components), leaving some ambiguity in sibling differentiation.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'ng_add' over sibling tools like 'ng_update' for package management or 'ng_generate' for adding components, nor does it specify prerequisites or exclusions. This lack of contextual usage information leaves the agent without clear direction.

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

• ng_generateC
  2.9/5.0
  Behavior2/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 mentions creating artifacts but lacks details on permissions, side effects (e.g., file system changes), error handling, or output format. For a tool that likely modifies files, this is a significant gap in behavioral disclosure.

  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, efficient sentence that front-loads the core action and purpose without any wasted words. It directly communicates the tool's function in a structured and clear manner.

  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 the tool's complexity (5 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain what happens after generation, error cases, or the impact of options like 'force' or 'dryRun', leaving critical context gaps for a file-creating tool.

  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 fully documents all 5 parameters. The description adds no additional meaning beyond implying 'schematic' and 'name' are used for artifact generation, but it doesn't clarify parameter interactions or usage beyond what the schema provides, meeting the baseline for high coverage.

  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 the verb ('Run ng generate') and resource ('to create a new Angular artifact'), specifying examples like component and service. It distinguishes from siblings like ng_add or ng_new by focusing on artifact generation rather than adding packages or creating new projects, though it doesn't explicitly contrast them.

  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?

  The description provides no guidance on when to use this tool versus alternatives like ng_add or ng_new, nor does it mention prerequisites or context for generating artifacts. It simply states what the tool does without indicating appropriate scenarios or exclusions.

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

• ng_newC
  2.9/5.0
  Behavior2/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 of behavioral disclosure. It mentions the tool creates a new workspace, implying a write operation, but doesn't cover critical aspects like side effects (e.g., file system changes), permissions needed, error handling, or output format. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

  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 the tool's complexity (creates a new Angular workspace with 4 parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, potential side effects, or how it interacts with the system, leaving the agent with incomplete information for safe and effective use.

  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 description coverage is 100%, with all parameters well-documented in the input schema. The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Since the schema does the heavy lifting, 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.

  Purpose4/5

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

  The description clearly states the action ('Run ng new') and the outcome ('create a new Angular workspace'), providing a specific verb and resource. However, it doesn't differentiate this tool from its siblings (e.g., ng_add, ng_generate), which might also create or modify Angular projects in different ways, so it doesn't reach the highest score.

  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?

  The description provides no guidance on when to use this tool versus alternatives like ng_add or ng_generate, nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.

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

• ng_runC
  2.9/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 behavioral disclosure. It mentions execution but doesn't clarify if this is a read-only or destructive operation, what permissions are needed, or any side effects like file modifications. This is inadequate for a tool that likely performs builds or similar actions.

  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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, earning full marks for conciseness.

  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 the complexity of executing custom architect targets (likely involving builds or deployments), no annotations, and no output schema, the description is insufficient. It doesn't explain what happens during execution, potential outputs, or error handling, leaving significant gaps for the agent.

  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 parameters thoroughly. The description adds no additional meaning beyond implying 'ng run' execution, which is redundant with the tool name. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 the action ('Run') and resource ('custom architect target'), making the purpose understandable. However, it doesn't differentiate from sibling tools like ng_generate or ng_update, which also execute Angular CLI commands, so it doesn't reach the highest clarity level.

  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 guidance is provided on when to use this tool versus alternatives like ng_generate or ng_add. The description merely states what it does without context about appropriate scenarios or prerequisites, leaving the agent to infer usage.

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

• ng_updateC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the tool 'updates Angular packages and run migrations' which implies mutation/write operations, but doesn't disclose important behavioral aspects like whether this modifies project files, requires specific permissions, has side effects, or what happens on failure. For a complex update tool with 11 parameters, this is inadequate.

  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 extremely concise - a single sentence that directly states the tool's purpose without any fluff or unnecessary elaboration. It's front-loaded with the core functionality and wastes no words.

  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?

  For a complex Angular update tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'run migrations' entails, what gets modified, potential risks, or typical use cases. The combination of high complexity and minimal description creates significant gaps for an AI agent.

  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 provides no parameter-specific information, but with 91% schema description coverage, the input schema already documents most parameters well. The baseline score of 3 is appropriate since the schema does the heavy lifting, though the description adds no value beyond what's in the structured 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 the action ('Run ng update') and purpose ('to update Angular packages and run migrations'), providing a specific verb+resource combination. It doesn't explicitly differentiate from sibling tools like ng_add or ng_generate, but the focus on updating packages is reasonably distinct from adding packages or generating code.

  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?

  The description provides no guidance on when to use this tool versus alternatives like ng_add or ng_generate, nor does it mention prerequisites or typical contexts for running Angular updates. It simply states what the tool does without usage context.

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