Server Quality Checklist

Tool Scores

• dependenciesB
  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 burden of behavioral disclosure. It usefully describes the graph's directionality—incoming and outgoing imports—but it does not state whether the operation is read-only, what errors may occur, or how the graph is returned.

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

  Conciseness5/5

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

  A single well-structured sentence with no filler. The dash construction front-loads the core concept and then clarifies it concisely.

  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 one-parameter tool with no output schema or annotations, the description gives a usable high-level contract: a dependency graph of a file in both directions. However, it lacks usage context, return-format details, and edge-case or exclusion information, so it is only minimally complete.

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

  Parameters3/5

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

  The schema already documents the single parameter with 100% coverage ('Chemin du fichier'). The description reinforces that the path refers to a file ('d'un fichier') but adds no new validation or format details; this meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description identifies a concrete analysis resource: a file dependency graph, and clarifies both directions ('qui il importe et qui l'importe'). It makes the tool's purpose clear, though it does not explicitly contrast it with siblings such as 'graph' or 'impact'.

  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 given about when to choose dependencies over sibling tools like graph, impact, or search. The description states only what the tool produces, leaving the agent to infer use cases and alternatives.

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

• route_guardB
  3.4/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 disclosing behavior. It states that the tool 'detects' certain route problems, which implies a read-only analysis, but it does not explicitly state whether invocation has side effects, what it returns, or how results are presented. This is a notable gap for a tool with no annotation safety hints.

  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 or repetition. The first sentence establishes the scope and the second enumerates the precise detection categories. Every phrase contributes usable information to an agent.

  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 zero-parameter tool, the description adequately states the purpose and detection targets. However, with no output schema and no annotations, it does not explain what output format or behavior to expect after invocation. An agent can decide to call it but cannot anticipate how to interpret the result.

  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 there is nothing for the description to explain about parameter semantics. The description correctly avoids inventing parameter details. The baseline of 4 applies because the schema already fully covers the (empty) parameter surface.

  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 names a specific resource, frontend↔backend route coherence, and lists three concrete detection categories: unused backend routes, nonexistent frontend targets, and sensitive routes without auth. This is clear and materially distinct from generic sibling names like 'guard' or 'check', though it does not explicitly differentiate itself from those siblings.

  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 tool's purpose implies when to use it: to validate route coherence and surface route-related issues. However, it gives no explicit usage context, prerequisites, or guidance on when to choose this tool over siblings such as 'guard', 'check', or 'health'. The guidance is only implicit.

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

• statusB
  3.4/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 of behavioral disclosure. It implies a read-only status snapshot by saying 'Etat de l'index', and it discloses the content of the returned information. However, it does not explicitly state that no mutation occurs, nor does it define 'fraicheur' or mention any operational caveats such as freshness thresholds or staleness behavior.

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

  Conciseness5/5

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

  The description is a single compact sentence with no filler. It front-loads the core subject ('Etat de l'index') and immediately enumerates the meaningful output fields. Every part contributes useful 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?

  Given the tool has no parameters and no output schema, the description provides the essential return fields but leaves some ambiguity around the meaning of 'fraicheur' and how it is measured. It is adequate for a basic status call, but it does not fully define the output semantics or clarify how this status tool relates to the many sibling tools. A bit more context would make it 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, and the schema is empty with 100% coverage, so there are no parameter semantics to explain. The baseline of 4 applies because no compensation is needed; the description does not need to add parameter detail where none exists.

  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 that the tool reports the state of the index and lists the specific fields it returns: date, number of files, and freshness. It does not use a verb, but the noun 'Etat' plus the listed attributes makes the purpose understandable. It is not explicitly differentiated from siblings like health or check, though the listed fields help distinguish it.

  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 about when to use this tool versus alternatives such as health, check, or impact. The description only states what the tool reports, not the context in which it is the appropriate choice or when another tool should be selected instead.

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

• regression_mapA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. 'Liste' implies a read-only operation and 'impactes en cascade' discloses that results include transitive impacts, which is useful. It does not mention error conditions, assumptions about source code, or whether results are static or derived live, but the core behavior is clear enough for a listing 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 compact and front-loaded with the user's question, which makes the intent immediately graspable. The leading 'Regression map' slightly repeats the tool name, and the quoted question could be tighter, but no meaningful context is wasted.

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

  Completeness4/5

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

  For a one-required-parameter tool with no output schema, the description gives the essential call intent and enumerates the result categories: pages, API routes, and entry points. It does not specify exact return formatting or ordering, but those are not necessary for a correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with filePath already described as 'Chemin du fichier modifie (absolu ou relatif)'. The description adds no new parameter semantics; the phrase 'je modifie ce fichier' restates what the schema already communicates. The baseline of 3 applies because the schema handles the parameter documentation fully.

  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 anchors the tool to a concrete use case ('je modifie ce fichier, quelles pages/routes retester ?') and names a specific action plus resource: 'Liste les pages, routes API et entry points impactes en cascade.' It differentiates the tool from generic siblings like impact or dependencies by focusing on regression retesting, though it does not explicitly name alternatives.

  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 quoted scenario makes the triggering condition obvious: use it when a file is modified and you need to know what to retest. However, there is no explicit when-to-use vs. when-not-to-use guidance, and no alternatives such as impact or dependencies are mentioned.

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

• reindexA
  3.5/5.0
  Behavior2/5

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

  No annotations exist, so the description must carry full behavioral disclosure. It does explain the full vs incremental re-indexing behavior, but omits side effects on the existing index, potential cost or duration, and whether reindexing is destructive or safe.

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

  Conciseness5/5

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

  A single, compact sentence front-loads the core action and clearly communicates both the default mode and the parameter option. No unnecessary words 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 one-optional-parameter tool, the description covers the core operation and the parameter's effect, and no output schema is present to require return-value details. However, with no annotations and no guidance on when to invoke it, the contextual picture is only minimally 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 input schema already documents the incremental parameter with 100% coverage, but the description adds the crucial default behavior ('Par defaut complet') that the schema does not state. This clarifies what happens when the parameter is omitted.

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

  Purpose5/5

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

  The description states a specific action and resource: 'Re-indexe le projet'. It also distinguishes behavior by default vs incremental, making the tool's role clear even among many 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 reindex versus alternatives like status, check, guard, or impact. The description explains the incremental option but not the context or prerequisites that should trigger this tool.

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

• searchA
  3.5/5.0
  Behavior2/5

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

  With no annotations at all, the description carries the full burden of disclosing behavior. It reveals the scope of the search (imports, exports, functions, classes, types, routes) but does not state what the tool returns, whether it is read-only, how matches are matched, or any limits. For a search tool without an output schema, this leaves key behavior undisclosed.

  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 then expands with the search scope. 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 one-parameter search tool, the description is mostly complete: it states what is searched and the intended query. However, since there is no output schema and no annotations, the missing information about result format (e.g., locations, matches, counts) leaves a notable gap for an agent deciding whether the tool fits its task.

  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 query parameter is already documented as 'Nom de la fonction, du type, du hook ou de la route a chercher'. The description reinforces this by adding search targets like imports/exports/classes, but it does not add fundamentally new parameter semantics 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 starts with a specific verb ('Recherche dans la carte') and a concrete user question ('qui utilise cette fonction/type/hook ?'), then enumerates the search targets (imports, exports, fonctions, classes, types, routes). This clearly distinguishes it from siblings like dependencies or graph: it is a usage/reference lookup tool.

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

  Usage Guidelines3/5

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

  The description implies the tool is for finding who uses a given symbol by name, which gives a clear context. However, it does not explicitly state when to use this tool over siblings such as dependencies, impact, or graph, nor does it mention any exclusions or alternatives.

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

• guardA
  3.6/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 burden of disclosing behavior. It does state what the tool returns and that it is a pre-change check, which is useful. However, it does not explicitly say whether the check itself is read-only, what happens on failure, or whether any side effects occur.

  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 concise and front-loaded with the core purpose, then lists outputs and timing. The quoted question 'est-ce safe de modifier ce fichier ?' is slightly redundant with 'Pre-change safety check' but still helps clarify intent without bloating the text.

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

  Completeness4/5

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

  For a single-parameter tool with no output schema, the description gives essential context: when to call it, what it evaluates, and what it returns. It does not cover error conditions or alternative tools, but the tool is simple enough that the description is reasonably complete.

  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 schea covers 100% of the single parameter, already describing filePath as 'Chemin du fichier qui va etre modifie (absolu ou relatif)'. The description adds context about pre-change checks and go/no-go outputs but does not add meaning beyond the schema for the parameter itself.

  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 a pre-change safety check on a file and states the outputs: risks, files to verify, and a go/no-go recommendation. It does not explicitly name or differentiate any sibling tool, but the purpose is specific enough that an agent can tell it apart from generic checks like status or health.

  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 'A appeler AVANT toute modification', giving a strong when-to-use instruction. It does not mention alternatives or when not to use this tool, so it stops short of full guidance.

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

• changelogA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It indicates a read-only display via 'Montre', but it does not mention whether a prior reindex is required, how the diff is formatted, or any edge cases. It is not contradictory, just minimal.

  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, structurally clean sentence. It front-loads the core action ('Diff lisible') and then lists the specific content covered. No filler, repetition, or unnecessary words.

  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, read-only tool, the description sufficiently covers what the tool displays and the relevant timeframe. It doesn't describe the output format, but with no output schema and a clear 'readable diff' concept, it is likely enough for the agent to invoke correctly.

  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 with 100% coverage, so there is no parameter information to add. The baseline of 4 applies because no parameters exist and the description doesn't need to explain them.

  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 function: it shows a readable diff between the old and new index, listing specifically files, exports, routes, and types that were added/removed/modified. While it doesn't explicitly distinguish itself from siblings like whatsnew or status, the focus on 'diff' and 'reindex' makes the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The phrase 'depuis le dernier reindex' implies the tool is useful after a reindex to inspect changes, giving some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

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

• healthA
  3.7/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 of behavioral disclosure. It does well by specifying what criteria are analyzed and the output grading scale (A-F), giving an agent a concrete sense of what the tool computes and returns. It does not mention side effects, but the nature of a health score strongly implies a read-only analysis.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the core purpose (global health score) and then provides concrete detail. Every phrase adds value without 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?

  For a parameterless tool with no output schema, the description adequately covers the return value (letter grade A-F) and the key input factors. It could be slightly more explicit about whether the output includes detailed breakdowns or just the single grade, but overall it is complete enough for an agent to invoke correctly.

  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?

  This tool has zero parameters and the schema coverage is 100%, so there is no parameter information missing. The baseline of 4 for a parameterless tool applies, and the description does not need to compensate for any schema gaps.

  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 produces a global project health score and lists the specific factors it evaluates (broken imports, orphan files, circular dependencies, high-risk files). This provides a specific resource and output format, though it does not explicitly differentiate itself from sibling tools by name.

  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 about when to use this tool versus alternatives like status, dependencies, or check. The description implies it is for assessing overall project health, but no explicit usage conditions, alternatives, 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.

• checkA
  3.8/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 reveals core behavior (re-indexing, comparing, detecting removed exports, broken imports, and inconsistent types), but does not disclose potential side effects, output shape, or error behavior.

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

  Conciseness5/5

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

  One dense sentence front-loads the tool's purpose and immediately follows with concrete behavior and an explicit usage condition. Every phrase earns its place.

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

  Completeness4/5

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

  For a one-parameter tool with full schema coverage, the description is adequate for an agent to know when and how to invoke it. It does not describe the return format, but the low complexity and procedural framing make this a minor gap.

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

  Parameters3/5

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

  Schema coverage is 100%: the single required filePath parameter is already described in the schema as the just-modified file. The description adds little beyond that, so the schema carries the semantic weight.

  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?

  Starts with 'Post-change coherence check' and states specific actions: 're-indexe le fichier modifie, compare avec l'ancien etat, detecte les exports supprimes, imports casses et types incoherents.' This gives a clear verb, resource, and scope, though it does not explicitly contrast with siblings like reindex.

  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?

  Includes an explicit trigger: 'A appeler APRES chaque modification.' This clearly indicates when to use it, but it does not mention when not to use it or name alternative sibling tools.

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

• whatsnewA
  3.8/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 behavioral burden. The verbs 'Resume' and 'Montre' strongly imply a read-only summary operation and the dependency on 'dernier reindex' is disclosed. Still, it does not explicitly state that the tool has no side effects, nor does it mention authorization requirements, performance, or what happens if the index is missing.

  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?

  Three short French sentences, each earning its place: the first defines the tool's core behavior, the second gives a concrete usage moment, and the third details the output content. The purpose and usage are front-loaded with no filler.

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

  Completeness4/5

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

  For a simple, optional-parameter, summary-style tool, the description is quite complete: it explains when to run it, what it is based on, and what information it will surface. It only lacks explicit side-effect or error-context details, which would matter more for a mutating tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents the optional 'since' parameter. The description partially reinforces its meaning by tying the default to the last reindex, but it does not add meaningful details beyond what the schema provides.

  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 a specific resource and action: it resumes project changes since the last reindex and lists exactly what is shown (modified files, changed signatures, new routes, most active files). However, it does not explicitly differentiate itself from the sibling tool 'changelog', which likely overlaps substantially.

  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 guidance to run this tool at the beginning of a session to understand context. It does not, however, mention when not to use it or how it relates to alternatives like changelog or status, which would be even more helpful.

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

• external_mapA
  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. It discloses that the tool analyzes and maps external dependencies and risk, which suggests a read-only diagnostic behavior, but it does not explicitly state whether it has side effects, requires network access, or reports results in a particular format.

  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 action and lists concrete item categories. No filler or redundant details are present.

  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 analysis tool, the description is reasonably complete: it explains what is mapped and why to run it. However, with no output schema, it could further clarify the output format or how the risk interpretation is presented.

  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 and schema coverage is 100%, so parameter documentation is unnecessary. The description still usefully indicates what categories will be examined, which is the relevant semantic content.

  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's purpose: mapping external project connections (npm packages, environment variables, outgoing API calls). The verb 'cartographie' is specific and the resource scope is explicit, but it does not explicitly differentiate this tool from sibling tools like 'dependencies' or 'graph'.

  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: 'A lancer pour comprendre les dependances externes et detecter les risques.' It tells the agent when to use the tool, though it does not mention conditions where another tool would be preferable or provide exclusions.

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

• silent_catchA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry behavioral info. 'Detecte' implies a read-only analysis, and the examples clarify what counts as a silent catch. However, it does not disclose whether the tool returns matches, modifies anything, requires permissions, or how it interacts with the wider codebase—so behavioral coverage 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 compact: one sentence states the core purpose with concrete examples, and a second clause gives explicit usage context. Every part earns its place, with the main action front-loaded and no redundant filler.

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

  Completeness4/5

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

  For a tool with one optional parameter, full schema coverage, and a clear analytical purpose, the description supplies enough to select and invoke it correctly. It covers what is detected, example patterns, and when to run it. It does not describe the output format, but with no output schema this is a minor gap given 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?

  Schema description coverage is 100% and the single 'severity' parameter has enum values plus per-value explanations. The description adds no parameter-specific detail, but it does not need to because the schema fully documents the parameter. Baseline of 3 applies.

  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 ('Detecte') and resource ('les blocs catch qui avalent les erreurs silencieusement'), and gives concrete examples: 'catch vides, return sans log, .catch(() => default)'. This clearly distinguishes it from general sibling tools like 'check' or 'guard' by naming its exact search target.

  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?

  It gives explicit usage timing: 'A lancer lors d'un audit ou apres /review'. This tells the agent when the tool is appropriate, though it does not explicitly name alternatives or say when not to use it. Since no sibling tool appears to target silent catches, the guidance is clear enough.

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

• graphA
  4.1/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output format (Mermaid diagram) and the two behavioral modes (full graph vs centered with 2 levels). It could say more about what '2 levels' includes, but the core behavior is 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 two short sentences with no filler. The main action is front-loaded, and the behavioral distinction is stated compactly.

  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 simple tool with no output schema and one optional parameter, the description covers the essential context: what it does, the output type, and how the parameter changes behavior. It does not over-explain, and nothing critical seems missing for correct invocation.

  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 extra meaning beyond the schema by specifying the '2 niveaux' depth behavior for filePath, which the schema does not mention. This is genuine added value.

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

  Purpose4/5

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

  The description uses a specific verb and resource: 'Genere un diagramme Mermaid du graphe de dependances.' It clearly states what the tool produces. It does not explicitly differentiate from the sibling 'dependencies', but the Mermaid output makes it distinct enough.

  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: without filePath produces the complete graph, with filePath produces a graph centered on that file with 2 levels. It does not name alternatives or exclusions, but the optional-parameter guidance is explicit and actionable.

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

• impactA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool 'retourne' (returns) a report, implying a read-only analysis, and enumerates the exact result categories. A brief explicit 'read-only' statement or mention of analysis limitations would make it stronger.

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

  Conciseness5/5

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

  The description is compact and front-loaded: a clear label, a relatable usage question, and a concise list of outputs. Every part contributes to understanding the tool without redundant 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?

  For a single-parameter tool with no output schema, the description adequately covers the invocation trigger and the three categories of returned information. It does not elaborate on the risk-score scale or exact response structure, but those are minor gaps given 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 documents the only parameter, filePath, with a clear description of 'absolute or relative to the project' — giving 100% schema coverage. The tool description merely references 'this file' in the usage example and adds no additional parameter semantics beyond the schema, so the baseline 3 applies.

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

  Purpose5/5

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

  The description names a specific function — impact analysis — and frames it with a concrete scenario: 'I modify this file, what breaks?' It also lists three distinct outputs (affected files, affected API routes, risk score), which clearly separates it from sibling tools like status, search, and dependencies.

  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 embedded question 'je modifie ce fichier, qu'est-ce qui casse ?' clearly communicates when to use the tool: before modifying a file to understand potential breakage. It does not explicitly exclude alternatives such as dependencies or graph, so it lacks the exclusion criteria needed for a 5.

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

• schema_checkA
  4.4/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the behavioral burden. It discloses that the tool detects coherence issues rather than mutating anything, and it scopes the behavior to missing fields and enum drift. It does not mention output or side effects, but for a detection tool this is adequate.

  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?

  Three short sentences: scope, specific checks, and run trigger. Every sentence earns its place and the key purpose is front-loaded. No filler or 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?

  For a zero-parameter check tool with no output schema, the description provides enough context: what is checked, what kinds of problems are found, and when to run it. It could mention how results are reported, but that is not essential given the simplicity of the tool.

  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 for the description to document beyond the fact that it needs none. The context about when to run it adds practical meaning even though no parameter details are required.

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

  Purpose5/5

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

  The description names a specific resource (Prisma schema, backend DTOs, frontend types) and a specific action: detecting missing fields and desynchronized enums. This clearly distinguishes schema_check from generic siblings like status or check.

  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 states when to run the tool: after modifying the Prisma schema or DTOs. It does not list alternatives or when-not-to-use, but the trigger context is clear enough for an agent to select it appropriately.

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