Server Quality Checklist

Tool Scores

• module_mapB
  3/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 behavioral disclosure. It indicates a read operation ('quick read') but does not describe the output format, whether it is safe or has side effects, or any constraints like repository requirements or limit behavior. This is a significant gap for a 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.

  Conciseness4/5

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

  The description is a single, front-loaded sentence that conveys the core purpose efficiently. It has no filler, but it is under-specified, so it could be more informative. However, for the information it does provide, it is 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 annotations, the description is too minimal. It does not clarify what the return data looks like, how the 'limit' parameter affects results, or what happens when `repo` is omitted (since no params are required). The tool's complexity is low, but the absence of critical behavioral and parameter details makes the description incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain either parameter. The `repo` string and `limit` integer are not described at all, and with no parameter details in the schema, the agent cannot infer their role or defaults. The description does not compensate for the schema's silence.

  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 a specific action: aggregates import edges to top-level directories, and gives the purpose of providing a quick architectural read. This differentiates it from sibling tools like who_calls or path_between by focusing on top-level aggregation rather than detailed relationships.

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

  Usage Guidelines3/5

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

  The phrase 'quick read on the architecture' implies use when an overview is needed, but it does not explicitly mention when not to use it or name alternatives. There is no explicit guidance on choosing this over sibling tools, so the usage context is only mildly implied.

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

• path_betweenB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description bears the full burden of disclosing behavior. It explains that the tool shows how control flows, implying a read-only traversal, but it does not describe what the output looks like, how errors (e.g., no path found) are handled, or any side effects. The extra wording beyond the title adds only a modest conceptual clarification.

  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-crafted sentence that immediately conveys the core purpose. It is front-loaded with the main idea and the example adds value without unnecessary length. Every word earns its place.

  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 (4 parameters, no output schema, 0% schema coverage), the description is insufficiently complete. It lacks parameter semantics, return value information, and explicit usage conditions. The example helps but does not compensate for the missing critical details needed for correct invocation.

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

  Parameters1/5

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

  The input schema has 0% coverage, and the description does not explain any of the four parameters (from, to, repo, maxDepth). It fails to indicate that 'from' and 'to' are symbols or how 'maxDepth' affects the search. The description entirely omits parameter semantics, which is critical given the complete lack of schema descriptions.

  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 this tool finds the shortest call path between two symbols, distinguishing it from sibling tools like who_calls and what_it_calls. The example 'from an HTTP handler to a database write' concretely illustrates the purpose and adds specificity beyond the title.

  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 example but does not explicitly state when to prefer this tool over alternatives like who_calls or what_it_calls, nor does it mention any exclusions or prerequisites. The example provides context, but no direct guidance is given.

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

• what_it_callsB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It does disclose the key behavior of transitive traversal ('everything this symbol calls, transitively'), but omits details about depth limits, cycle handling, result granularity, or any side effects, leaving notable gaps.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the dash-separated metaphor adds clarity without bloat.

  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 three parameters, no annotations, and no output schema, the description is too sparse. It fails to explain the semantics of repo and depth, the return format, or how it relates to sibling graph-query tools, which is necessary for effective tool selection and invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, yet the description does not compensate by explaining the three parameters. It only implicitly references 'symbol' via the title, and says nothing about what 'repo' and 'depth' mean or how they affect the result.

  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 title and description clearly identify the action (find callees) and the resource (a symbol). The phrase 'Everything this symbol calls, transitively' precisely conveys the downstream traversal, distinguishing it from sibling tools like who_calls which find callers.

  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—exploring the downstream surface of a function—but provides no explicit guidance on when to prefer this over who_calls or impact_of, nor any exclusions or conditions. The context is clear but not formalized.

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

• drop_repoB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden of behavioral disclosure. It does state the operation is 'Irreversible' and that it deletes 'every node', which are key traits. However, it omits other relevant behaviors such as permission requirements, potential side effects on other repositories, and error behavior, so it is only partially transparent.

  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 short sentences that front-load the action and add the crucial irreversibility warning. Every word earns its place, with no fluff or repetition.

  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?

  This is a simple one-parameter tool with no output schema and no annotations. The description covers the core action and irreversibility, but it does not address potential return values, success/failure reporting, or what happens to related data, leaving some contextual gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description implies the 'repo' parameter identifies a repository but does not specify the expected format (e.g., name, ID, path) or any constraints beyond the schema's type string. This leaves the parameter semantics underdefined.

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

  Purpose5/5

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

  The description clearly states the action ('Delete') and the resource ('every node belonging to a repository'), which aligns with the title 'Remove a repository from the graph'. This distinguishes it from sibling tools like list_repos and index_repo.

  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. The only hint is 'Irreversible', which is a warning but not a usage guideline. No prerequisites, exclusions, or comparison with sibling tools are given.

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

• find_symbolA
  3.6/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 explaining behavior. It discloses matching semantics (bare/qualified names, substring fallback) but does not mention other important traits such as case sensitivity, behavior on multiple matches, or whether the repo parameter is required for scoping. The provided behavior is useful but incomplete.

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

  Conciseness5/5

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

  The description is two sentences long and front-loaded with the primary purpose. Every sentence adds value: the first states the core function, the second explains input flexibility and fallback behavior. There is no filler or redundancy.

  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 has 3 parameters and no output schema or annotations. The description adequately covers the name parameter and overall purpose, but it lacks explanation of the repo parameter and expected return value or error behavior. It is not a complex tool, but the gaps in parameter and output information make it incomplete.

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

  Parameters2/5

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

  Schema description coverage is only 33% (only 'name' is described). The description adds meaningful semantics for 'name' (bare/qualified, substring matching) but says nothing about 'kind' or 'repo'. Since coverage is low, the description should compensate fully, but it only partially does so, leaving two of three parameters unclear.

  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: 'Locate the definition of a function, class or method by name.' It specifies a concrete verb and resource, and the scope (by name) distinguishes it from siblings like who_calls and what_it_calls, which focus on call relationships rather than definitions.

  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 on accepted name formats ('bare name' or 'qualified one') and fallback behavior ('substring matching'), which implies when to use it. However, it does not explicitly state when to prefer this tool over siblings or provide exclusions, so guidance is more implied than explicit.

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

• hotspotsA
  3.6/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. It discloses that results are 'ranked by in-degree' and explicitly notes compatibility ('works on Neo4j AuraDB Free, no GDS required'), which is useful technical context. However, it does not mention whether the operation is read-only, any side effects, or the exact return format, leaving some ambiguity.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core purpose, and includes only valuable additional context (ranking method and compatibility). Every word earns its place — no fluff or repetition.

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

  Completeness3/5

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

  For a simple read-only ranking tool with two parameters and no output schema, the description is adequate but incomplete. It tells the agent what is returned (ranked list of symbols) but omits parameter semantics and any caveats about repositories or limits. Given the zero-coverage schema, a bit more detail would make it fully self-sufficient.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no information about the 'repo' or 'limit' parameters. The tool's purpose implies 'repo' is the repository to analyze and 'limit' caps results, but the agent is left to infer this without any guidance on defaults, format, or role. The description completely fails to compensate for the lack of schema documentation.

  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 what the tool does: it identifies 'symbols with the most distinct callers' and ranks them. The phrase 'the code where a mistake propagates furthest' adds intent. This distinguishes it from siblings like who_calls (which traces callers of a specific symbol) and impact_of (which likely analyzes a given symbol's impact).

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: to find high-risk code where mistakes have broad reach. It does not explicitly name alternatives or give 'when not to use' instructions, but the use case is implicit and distinct from sibling tools that focus on individual symbols or paths.

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

• list_reposA
  3.8/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 full burden. It does convey that this is a read-only enumeration ('Which repositories are in the graph') and the returned information, but it does not mention sorting, pagination, or clarify the term 'graph'. It is minimally transparent but not richly detailed.

  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 filler. Every word adds meaning: 'Which repositories', 'in the graph', and 'how many files each has' together convey the purpose and output efficiently.

  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 zero-parameter list tool, the description adequately covers the output shape (repositories and file counts). However, since there is no output schema and no annotations, a slightly more explicit return structure or a note that it is read-only would make it more complete. It is nearly sufficient but not perfect.

  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 input schema has zero parameters, so the baseline score is 4. There are no parameter semantics for the description to explain, and the schema coverage is trivially complete.

  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 title 'List indexed repositories' supplies the verb, and the description specifies exactly what is returned: which repositories are in the graph and their file counts. This clearly distinguishes it from sibling tools like path_between, index_repo, and drop_repo, which serve different purposes.

  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. The description only states what is listed, without any when-to-use or when-not-to-use context, so an agent has no explicit help choosing among siblings.

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

• who_callsA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosure and does a good job by explaining that the tool returns every symbol that reaches the target through the call graph, with nearest-first ordering. It does not disclose output format or performance limitations, but the core traversal behavior is clearly conveyed.

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

  Conciseness5/5

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

  The description is two sentences with no filler: the first states the core behavior, and the second provides a useful analogy to grep. Every word earns its place, making it highly concise and well-structured.

  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 captures the main purpose and ordering but omits any detail about the return payload, the repo parameter, or prerequisites like indexing. Given the lack of an output schema and annotations, a bit more detail would be helpful, though the tool's simplicity keeps it at an adequate level.

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

  Parameters2/5

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

  The description adds no information about the parameters (repo, depth, symbol). The schema already describes symbol and depth, but repo has no description, and the tool description does not clarify its role or how depth affects the results, so it fails to supplement 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 defines the tool's purpose: it finds all symbols that reach the given one through the call graph, ordered by distance. It also distinguishes itself from grep and implicitly from sibling tools like what_it_calls (callees) by emphasizing it finds callers, not the symbol definition.

  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 call-graph analysis but never explicitly states when to prefer this tool over siblings or when not to use it. It only contrasts with grep, not with other tools like find_symbol or impact_of, leaving the agent to infer the appropriate context.

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

• impact_ofA
  4.1/5.0
  Behavior4/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 reveals that the tool returns transitive upstream callers, separates production callers from tests, and treats an empty test list as a signal that the change is unguarded. This goes beyond a generic 'impact analysis' phrase, though it doesn't discuss parameters, output format details, or potential performance costs.

  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, and every clause adds value. The warning about empty test lists and the 'check before editing shared code' guidance are compact and actionable without unnecessary fluff.

  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 and sparse parameter docs, the description covers the essential output structure (production callers vs tests) and provides interpretation guidance (empty test list = unguarded). It leaves minor gaps around symbol formatting and depth semantics, but the schema covers depth, and the core use case is well specified.

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

  Parameters2/5

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

  Schema coverage is only 33% because only 'depth' has a description. The tool description does not explain the meaning of 'symbol' (e.g., whether it needs a fully qualified name) or 'repo' (e.g., optional or default repository). Since coverage is low, the description should compensate, but it only refers generically to 'this symbol.'

  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 direct question 'What breaks if this symbol changes' and clearly states the resource (a symbol) and the specific output (everything transitively upstream, split into production callers and tests). It distinguishes this from sibling query tools like who_calls or what_it_calls by emphasizing transitive upstream impact and testing coverage.

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

  Usage Guidelines4/5

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

  The description gives clear usage context: 'check this before editing shared code.' It implies this tool is for pre-edit impact assessment and even signals when to be cautious (empty test list means unguarded change). It doesn't explicitly contrast with siblings, but the 'before editing shared code' instruction provides a practical trigger.

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

• index_repoA
  4.1/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. It adds meaningful behavioral details: it skips unchanged files via content hash, supports specific languages, and persists to Neo4j. However, it does not disclose whether re-indexing replaces or merges existing graph data, whether Neo4j needs to be running, or any prerequisites. For a mutation tool, these are notable gaps.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action, then usage and supported languages. Every sentence serves a purpose with no filler. It is appropriately sized for the tool's scope.

  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 moderately complex (builds a code graph, has re-indexing behavior), and there is no output schema or annotations. The description covers the main action and re-indexing but omits operational details like whether existing graph data is updated or destroyed, whether Neo4j must be pre-configured, and what the tool returns. These are meaningful gaps for an AI agent deciding to invoke it.

  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%, so the baseline is 3. The description adds semantic value beyond the schema by explaining the content-hash skipping behavior, which gives context to the 'force' parameter (re-parse ignoring hashes). It also frames the 'repo' identifier through 'Run this once per project,' even though the schema already explains defaults.

  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: 'Parse a repository and build its code graph in Neo4j.' It uses a specific verb ('build') and resource ('code graph in Neo4j'), and distinguishes itself from sibling tools that are all query/analysis tools (e.g., find_symbol, hotspots) by being the indexing/setup step. Supported languages are also listed, adding clarity.

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

  Usage Guidelines4/5

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

  The description gives explicit timing guidance: 'Run this once per project, and again after significant changes.' It also explains the cost benefit ('unchanged files are skipped by content hash, so re-indexing is cheap'). While it doesn't explicitly mention when not to use it or alternatives, the context of sibling tools implies this is for initial setup, making the usage context clear.

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