Server Quality Checklist

Tool Scores

• compactD
  1.7/5.0
  Behavior1/5

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

  With no annotations, the description carries the burden of disclosing side effects, reversibility, and safety. It only states 'Compact code operations' and lists action names, without explaining what changes occur to files or code.

  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 very short but insufficiently structured for a tool with 9 actions; it's a bare list of action names without explanation, so it's under-specified rather than appropriately concise.

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

  Completeness1/5

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

  For a complex tool with 9 actions and 12 parameters, no output schema, and no annotations, this description is severely incomplete. It omits what each action does, expected outputs, and usage context.

  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?

  Input schema covers 100% of parameters with descriptions, so the schema does the heavy lifting. The tool description adds no parameter-level meaning beyond the schema.

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

  Purpose2/5

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

  The description 'Compact code operations' is vague and nearly restates the tool name without explaining what compacting involves. The list of actions provides some scope but doesn't specify a concrete verb-resource pair or distinguish this from sibling tools.

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

  Usage Guidelines1/5

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

  No guidance on when to use this tool vs alternatives; no context, prerequisites, or exclusions provided.

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

• dbC
  2.2/5.0
  Behavior1/5

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

  With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does not mention whether the tool performs read-only analysis, any side effects, permission requirements, or what it returns. The lack of any behavioral context makes this a significant gap.

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

  Conciseness3/5

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

  The description is extremely concise and lists the actions in a clear, scannable format. However, the brevity is more under-specification than effective conciseness, as it omits essential explanations while still being well-formed.

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

  Completeness1/5

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

  Given the tool has three distinct actions, no annotations, and no output schema, the description is completely inadequate. It fails to explain what schema, table_usage, and dead_tables do, what they return, or under what circumstances they should be invoked, leaving the agent without enough information to use the tool correctly.

  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 the parameters adequately. However, the description adds no additional meaning beyond the schema—for example, it does not elaborate on what each allowed action entails or how path and table interact.

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

  Purpose3/5

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

  The description states the tool performs 'Database analysis' and lists three specific actions, giving a general sense of its function. However, it lacks a clear verb+resource structure and does not explain what each action does, so it remains vague and does not distinguish itself from the similar sibling tool 'analyze'.

  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?

  There is no guidance on when to use this tool vs alternatives, nor is there any explanation of when each action (schema, table_usage, dead_tables) should be applied. The description simply lists the actions without context or prerequisites.

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

• filtersC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for disclosing behavior. It mentions actions like get/set/reset but gives no details on side effects, persistence, permissions, or return values, which is minimal and insufficient for a mutation-capable tool.

  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 a single, front-loaded sentence that lists actions without verbose filler. It is concise and easy to parse, though it could benefit from more structure to separate the actions' purposes.

  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 6 parameters and no output schema or annotations, the description is too minimal. It fails to explain the semantics of each action, when to use them, or what the tool returns, leaving significant gaps for a tool of this complexity.

  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's list of actions does not add parameter-level meaning beyond what the schema already provides, so it neither helps nor hurts.

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

  Purpose3/5

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

  The description states 'Filter configuration' and lists actions, giving a sense of the tool's purpose. However, it lacks a clear verb-resource structure and doesn't specify what 'filters' apply to, making it somewhat vague and not fully distinguishing from siblings.

  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 or when to prefer an alternative. The list of actions is present but without any context on prerequisites, use cases, or exclusions, leaving the agent without direction.

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

• testingC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full behavioral disclosure burden. It fails to describe side effects (e.g., what 'reset' does), state whether the tool mutates or reads data, or clarify any permissions or return values. The actions are listed without explaining their behavioral consequences.

  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 extremely concise: 'Test checklist management. Actions: pending|pass|fail|summary|reset' is front-loaded with the overall purpose and uses a compact list of actions. It wastes no words and is easy to parse.

  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 actions, 4 parameters) and the absence of annotations and output schema, the description is insufficient. It doesn't explain what each action does, how parameters relate to actions, or what the tool returns. The schema helps but the overall workflow is undocumented.

  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, with each parameter (path, action, reason, testId) documented in the schema. The tool description adds no extra parameter meaning—it only lists action names, which are already in the schema's enum. Therefore, the baseline of 3 applies.

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

  Purpose3/5

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

  The description states 'Test checklist management' and lists actions (pending|pass|fail|summary|reset), which conveys a general domain but lacks a specific verb+resource. It doesn't clearly state what the tool does with these actions (e.g., whether it updates statuses, lists tests, or generates reports). It also does not distinguish itself from sibling tools like 'filters' or 'analyze'.

  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 any context, prerequisites, or exclusions. The action list gives a hint for usage, but there is no explicit 'when to use' or 'when not to use' information.

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

• analyzeC
  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 does not state whether the tool is read-only, what permissions are needed, what output format to expect, or any side effects. The term 'analysis' implies non-destructive behavior, but that is not explicit, leaving significant ambiguity.

  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 a single concise sentence that front-loads the purpose ('Code quality analysis') and then lists actions. It is efficient, but the action list duplicates the schema enum values and could be better structured (e.g., separating the action list from the core description). Every word serves a purpose, though the list is somewhat unwieldy.

  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?

  This is a complex tool with 9 parameters, 2 required, and no output schema. The description does not explain what each action returns, how parameters like threshold or level affect behavior, or what the output looks like. The schema provides parameter descriptions, but the tool-level description is too sparse to enable correct invocation without additional research.

  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 does not add any parameter semantics beyond what the schema already provides—it merely repeats the action enum values. Since the schema fully documents all 9 parameters with descriptions, the tool-level description adds no extra meaning.

  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 states 'Code quality analysis' as the resource and lists specific action types, making the tool's purpose clear. It differentiates from sibling tools by focusing on analysis, though it doesn't explicitly compare to alternatives. The verb 'analyze' is implied by the name and action list, so it's more than a tautology.

  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, or how to choose among the listed actions. The action list implies use cases (e.g., dead_code, complexity) but lacks context on prerequisites, limitations, or when not to use it. This is a clear gap for a tool with multiple distinct modes.

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

• docsC
  2.9/5.0
  Behavior2/5

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

  Since no annotations are provided, the description must convey behavioral traits such as side effects or mutation risks. It only says 'management' and lists actions, failing to disclose that 'generate' can modify or overwrite files, that 'overwrite' controls this, or any other operational details.

  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 a single, efficient sentence that is front-loaded with the core purpose. It avoids unnecessary words, though it may be too brief to cover the tool's complexity.

  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?

  This multi-action tool with 6 parameters and no output schema needs a richer description explaining each action's purpose, expected return values, and side effects. The current text is a minimal overview and leaves agents to infer crucial operational details.

  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 already provides descriptions for 100% of parameters, so the baseline is 3. The description adds no extra meaning to any parameter; it merely recounts the action names already present in the enum.

  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 identifies the resource as '.ctx documentation' and lists concrete actions, making the tool's purpose clear. However, it doesn't elaborate on what each action does or how this differs from sibling documentation tools, so it falls short of 5.

  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 action list is present, but the description gives no indication of when to use this tool versus alternatives, nor when to select one action over another. The tool's name implies a scope, but there is no explicit context or exclusions.

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

• graph_metadataC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must convey behavior. It indicates read/validate operations, implying no mutation, but fails to disclose error handling, return shape, or side effects. It does specify 'project-local' scope, but otherwise lacks transparency about validation criteria or failure modes.

  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 short phrases with no fluff. It front-loads the core purpose and action list, making it easily scannable and appropriately concise.

  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 lack of an output schema and the presence of a nested metadata object, the description is too terse. It doesn't explain return values of get/validate, how the metadata parameter is used, or what 'validating' entails. A user cannot fully anticipate behavior from the description alone.

  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, so the schema already documents the three parameters. The description adds no new semantic detail beyond restating the action enum. Therefore the baseline of 3 applies.

  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 specific verbs 'read' and 'validate' with the resource 'project-local graph metadata sidecar', and clearly enumerates the two actions 'get|validate'. It identifies scope with 'project-local', but doesn't explicitly contrast with sibling tools, so the purpose is clear but not fully differentiated.

  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 does not state when to use this tool or provide alternatives. It lists actions but gives no guidance on choosing between get and validate, nor any conditions for when this tool is appropriate relative to other metadata tools. Usage is only implied by the action names.

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

• jsdocC
  2.9/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 of disclosing side effects, safety, and behavioral traits. It only states 'JSDoc operations' and action names; it does not mention whether generate writes files, whether checks are read-only, or any potential side effects. This is a significant gap for a tool that likely mutates files.

  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 a single, concise sentence that front-loads the purpose and lists actions compactly. It is efficient, though it could perhaps add a bit more context without bloating, but as written it is free of waste.

  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 should compensate but does not. It fails to explain return values, side effects, or usage context for the three actions. For a tool with multiple modes, this minimal description is insufficient for an agent to invoke it correctly in varied scenarios.

  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 already provides 100% coverage for all parameters with descriptions, so the schema does the heavy lifting. The description only repeats the action list, which adds no new semantic meaning beyond what the schema already offers, such as the purpose of path or maxDiagnostics. Thus, baseline 3 applies.

  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 tool as handling JSDoc operations and enumerates three specific actions (check_consistency, check_types, generate). This distinguishes it from sibling tools by domain, though it does not elaborate on what each action does beyond the action names.

  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 or when to choose one action over another. It only lists actions without any context, prerequisites, or exclusions, leaving the agent to infer usage solely from the action names.

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

• get_focus_zoneB
  3.2/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 'auto-detects from git' but does not state whether the operation is read-only, what 'enriched context' includes, how conflicts between useGitDiff and recentFiles are handled, or any side effects. This lack of detail is significant for a tool that may depend on git state.

  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 exceptionally concise: two sentences with no redundant information. Every word adds value, and the format is easy to parse quickly. It earns a perfect score for efficiency.

  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?

  Despite having three parameters and no output schema or annotations, the description is too brief. It does not explain the nature or structure of the 'enriched context' result, potential parameter combinations, or edge cases. This leaves the agent with insufficient information to fully understand the tool's behavior and output.

  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 67% (useGitDiff and recentFiles have descriptions; path does not). The description adds some context by mentioning 'explicit file list' and 'auto-detects from git', which aligns with recentFiles and useGitDiff. However, it does not clarify the 'path' parameter, so it only marginally improves on 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 the tool's purpose: 'Get enriched context for recently modified files.' It specifies the resource (recently modified files) and the action (get enriched context), with additional detail about auto-detection from git or explicit file lists. This distinguishes it from most siblings, though it does not explicitly contrast with similar tools like get_ai_context.

  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 usage context by explaining two modes: auto-detect from git or provide an explicit file list. This implies when the tool is useful (when needing context for recently modified files) but does not specify when to choose this over alternatives or any exclusions (e.g., when not to use git diff).

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

• navigateB
  3.2/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 transparency burden. It discloses one specific behavior: 'deps returns code calls plus web template/style/component links when present.' However, it does not explain the behavior of other actions, return formats, whether navigation is stateful, or any side effects. This is a minimal but not comprehensive 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 extremely concise: two sentences that state the core purpose and then list actions with a specific behavioral note about deps. There is zero redundant or filler content, and the key information is front-loaded.

  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?

  The tool has 5 parameters and no output schema, yet the description does not explain what each action returns or how parameters map to actions (beyond the schema's brief field descriptions). It lacks critical context like example usage, error handling, or the nature of the project graph. The schema covers parameter names but not the overall behavior, leaving the description insufficient for a multi-action 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?

  The input schema has 100% description coverage for all parameters, so the baseline is 3. The description itself only lists the action enum values and does not add meaning beyond the schema descriptions. It repeats the action list but provides no additional parameter context or usage examples.

  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 a specific verb and resource: 'Navigate the project graph' and enumerates five concrete actions (expand, deps, usages, call_chain, sub_projects). This provides a clear picture of the tool's scope, though it does not explicitly differentiate it from sibling tools like graph_metadata or analyze.

  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 lists possible actions but gives no guidance on when to choose this tool over sibling tools or when to use each action. There is no mention of scenarios, prerequisites, or exclusions. The action names imply some usage, but the description lacks explicit context for tool selection.

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

• check_custom_rulesB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits on its own. It only states that it 'Returns violations found,' which implies a read-only analysis but does not specify whether it modifies anything, requires special permissions, or how results are formatted. The lack of details beyond the basic output leaves significant behavioral uncertainty.

  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, compact sentence with no unnecessary words. It effectively states the action and expected result, earning full marks for conciseness and structure.

  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?

  Given no output schema and minimal behavioral context, the description is thin but adequate for a simple analysis tool. It covers the core function and return, but lacks details on output format, error handling, or side effects. For a tool with three parameters and no annotations, it is minimally complete but leaves room for improvement.

  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 for all three parameters (path, ruleSet, severity), so the schema already documents each parameter clearly. The description adds no extra semantic meaning beyond what the schema provides, giving a baseline score of 3.

  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 ('Run custom rules analysis on a directory') and its output ('Returns violations found'). It uses a specific verb and resource, distinguishing it from sibling tools like get_custom_rules and set_custom_rule which manage rules rather than execute analysis.

  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. There is no mention of prerequisites, limitations, or conditions under which another tool should be preferred. The purpose implies usage for analyzing a directory for rule violations, but no explicit context or exclusions are given.

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

• set_custom_ruleA
  3.7/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 discloses the side-effect of creating a ruleset if it does not exist, and 'Add or update' implies an upsert behavior. However, it does not mention whether existing rules are overwritten, permissions required, or what the return value or error states look like.

  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 action ('Add or update'), and includes the key side-effect. Every word earns its place, with no filler or redundant 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?

  For a simple write tool with no output schema and no annotations, the description covers the main purpose and the ruleset-creation side-effect. However, it lacks detail on what happens on success/failure, whether rules are overwritten, and any validation behavior, which would be helpful for an agent to fully understand the tool's 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?

  Schema description coverage is 100% for both parameters, so the schema already documents ruleSet and rule. The tool description adds no additional meaning about how to format or use the parameters, 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 clearly states the tool's action ('Add or update') and resource ('custom code analysis rule'), and adds the side-effect of creating a ruleset if needed. It is specific and distinct from sibling tools like get_custom_rules and check_custom_rules, which are read-only.

  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 for adding/updating rules but does not explicitly state when to use this tool versus the read-only sibling tools (e.g., get_custom_rules, check_custom_rules). The context of 'set' vs 'get'/'check' provides implied guidance, but no explicit exclusions or alternatives are mentioned.

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

• get_framework_referenceA
  3.8/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 burden of disclosure. It adds valuable behavioral context by explaining that the tool auto-detects the framework from the project and returns a structured set of documentation (API reference, patterns, common mistakes). For a read-only reference tool, this is substantial, though it does not explicitly state it has no side effects or permissions.

  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 concise, consisting of two sentences that are front-loaded with the core purpose. The first sentence states the verb and resource, and the second elaborates with mode and output details. No fluff or unnecessary repetition.

  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 has only two optional parameters, no annotations, and no output schema, the description covers the essential aspects: what it does, how it decides the framework, and what it returns. It could improve by explicitly mentioning when to prefer this over sibling documentation tools, but it is otherwise reasonably complete for the tool's simplicity.

  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 already has 100% coverage for both parameters, providing names and descriptions. The description does not add additional parameter semantics beyond what the schema provides, though it reinforces the auto-detect vs. explicit-name relationship. With high schema coverage, the baseline 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 tool's purpose: 'Get framework-specific AI reference documentation.' It specifies the resource (framework reference) and the action (get). However, it does not explicitly differentiate from sibling tools like 'docs' or 'get_usage_guide', so it lacks explicit sibling distinction.

  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 context about usage modes: auto-detection from project or explicit framework name. It implies the tool is used when framework-specific reference is needed, but it does not mention alternatives or when-not-to-use compared to sibling tools. Thus, it offers clear context but no exclusions or alternatives.

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

• get_agent_instructionsA
  3.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 full burden of behavioral disclosure. It states the tool's purpose but does not mention any side effects, safety profile, or whether the instructions are cached or dynamic. For a simple read-only getter this is acceptable, but it adds no contextual information beyond the action itself.

  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, focused sentence that front-loads the purpose and lists the three content categories. No wasted words, and the structure supports quick parsing.

  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 simple with no parameters, no output schema, and no annotations, but the description does not fully disambiguate from overlapping sibling tools like 'jsdoc' or 'get_custom_rules'. It covers the core content areas but may leave an agent unsure about the exact scope or relationship to other docs tools.

  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?

  There are zero parameters, so the description is not required to explain parameter semantics. The baseline for no parameters is 4, and the description also clarifies the content of the result, which adds value beyond the schema's empty properties.

  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 the specific verb 'Get' and identifies a concrete resource: coding guidelines, architectural standards, and JSDoc rules for the project. This clearly distinguishes it from sibling tools like get_usage_guide or get_custom_rules by naming the exact content domains.

  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 use when the agent needs project-level coding standards, but it does not explicitly state when to choose this tool over alternatives such as 'docs' or 'jsdoc'. No exclusions or alternative recommendations are given, so the guidance is present but implicit.

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

• get_skeletonA
  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. It discloses what the tool returns, the size reduction (10-50x), and that W web component summaries appear 'when present.' It is clear this is a read-only operation, but it does not mention potential performance impacts or error behavior, which would be useful.

  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 that conveys all essential information without waste. Every clause adds value.

  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 provides a clear list of what the output contains, enough to understand the tool's purpose and result. Since there is no output schema, this fills the gap. Missing details like edge cases or prerequisites prevent a 5, but it is largely complete for a simple single-parameter 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?

  The schema description covers the single 'path' parameter fully, so the description adds no extra meaning. Baseline 3 is appropriate since the schema provides sufficient semantics.

  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 'get a compact minified project overview' with explicit details (legend, stats, node summaries, file imports, W web component summaries). This distinguishes it from siblings like 'docs' or 'compact' by specifying the output format and size reduction.

  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 use case (getting a compact overview) but does not explicitly mention when to use this tool over alternatives or any exclusions. Sibling tools like 'compact' or 'get_focus_zone' are not referenced, so the guidance is indirect.

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

• get_custom_rulesA
  4.2/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 useful context about storage location (JSON files in rules/ directory), but it doesn't disclose potential errors, output format, or explicitly confirm read-only behavior. For a simple list tool, this is adequate but not comprehensive.

  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 concise (two sentences), front-loaded with the verb and resource, and every sentence earns its place by explaining what the tool does and where the data comes from.

  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 parameters and no output schema, the description is fairly complete: it states the action, the resource, and the storage location. It might miss explicit return value details, but for a simple listing tool the purpose is sufficiently clear.

  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?

  The tool has 0 parameters, which per guidelines warrants a baseline of 4. The description adds no parameter-specific information, but none is needed because the schema is empty.

  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 purpose with a specific verb ('List') and resource ('all custom code analysis rules'), and distinguishes it from sibling tools like set_custom_rule and check_custom_rules by indicating it's for retrieval.

  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 use when you need to see all rules, though it doesn't explicitly mention alternatives or exclusions. Given the sibling tool names, the context is clear without needing explicit guidance.

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

• invalidate_cacheA
  4.2/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It discloses the core action (invalidating the cached graph) but does not elaborate on side effects, what 'invalidate' means precisely (e.g., clearing vs. marking stale), or any persistence implications. For a simple cache invalidation tool, 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?

  The description is a single sentence that is front-loaded with the action ('Invalidate the cached graph') and includes a usage hint. There is no wasted wording.

  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 (no parameters, no output schema), the description covers the essential aspects: what it does and when to use it. It could mention what happens after invalidation, but for this complexity level, it is sufficiently complete.

  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?

  The tool has zero parameters, so there is nothing to describe. The baseline for zero parameters is 4, and the description does not need to compensate for any missing parameter information.

  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 'Invalidate' and specific resource 'cached graph', clearly stating its action. It stands out from sibling tools like graph_metadata or analyze because no other tool mentions invalidation.

  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 explicitly says 'Use after making code changes', providing a clear context for when to invoke. It does not mention alternatives or exclusions, but the guidance is direct and unambiguous.

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

• get_usage_guideA
  4.3/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. It discloses key behaviors: returns practical examples and workflows, supports topic filtering, and omitting topic returns the full guide. This sufficiently conveys the tool's read-only nature and content structure, though it does not detail output format or response size.

  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 sentences, front-loaded with purpose, then usage guidance, then topics. Every sentence provides valuable information without redundancy or fluff, making it concise and well-structured.

  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 getter with one optional parameter and no output schema, the description fully covers purpose, usage timing, available topics, and what the return contains. It is complete enough for an agent to decide when and how to invoke 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?

  Schema coverage is 100%, so the schema already documents the optional 'topic' parameter. The description reiterates the valid topics and adds the behavior of omitting the topic to get the full guide, but this does not significantly enhance meaning beyond the schema.

  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 ('Get') and clearly identifies the resource ('comprehensive usage guide for project-graph') and its content ('examples and best practices'). It distinguishes itself from sibling tools by positioning itself as the entry point for codebase analysis, navigation, or auditing.

  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 explicit guidance on when to use the tool: 'Call this FIRST when planning how to analyze, navigate, or audit a codebase.' This gives clear context, though it does not mention alternatives or when not to use it, so it falls short of a perfect score.

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

• get_ai_contextA
  4.6/5.0
  Behavior5/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 discloses that the tool auto-creates .contextignore on first call, returns 2-3k tokens in default mode, and auto-disables includeDocs/includeSkeleton when '*' is used. These are important behavioral traits that go beyond what the schema reveals.

  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 well-structured, using numbered modes to present the two behaviors. Every sentence adds meaningful information: the default mode, the wildcard mode, the .contextignore side effect, and when to use it. No filler or redundancy.

  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?

  Despite having no output schema, the description explains what the tool returns in both modes (skeleton+docs vs. all source code), the token footprint, and the auto-creation of .contextignore. It doesn't specify the output format (e.g., plain text vs JSON), but for an AI context bootstrapping tool this is likely acceptable. Overall, enough detail is provided for correct invocation and expectation setting.

  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 coverage is 100% and each parameter already has a detailed description. The description adds value by explaining the interaction between parameters: using includeFiles: ['*'] triggers a 'pure code dump' and automatically disables includeDocs and includeSkeleton. This cross-parameter semantics is not captured in the schema.

  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 that the tool 'boots AI agent context' and distinguishes two modes: default returns skeleton+docs, while includeFiles: ['*'] returns all compressed source code. It names the resource (project context) and explicitly positions itself as the first tool to call ('Call FIRST when starting work'), which differentiates it from siblings like get_skeleton and docs.

  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?

  Provides explicit guidance: 'Call FIRST when starting work' and advises using ['*'] for small/medium projects that fit in context. This implies for larger projects one should avoid the wildcard mode. It doesn't name alternative tools or explicitly state when not to use, but the guidance is clear and actionable.

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