io.github.neogeweb3/code-health-suite

by neogeweb3

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.1
Disambiguation3/5
Many tools are paired as detailed analysis vs. summary score (e.g., analyze_complexity vs. get_complexity_score), which can confuse agents about which to call. The full_health_check tool adds further overlap by covering many of the same metrics. However, the descriptions clearly distinguish 'analyze'/'scan'/'detect' from 'get_score' patterns, so the ambiguity is moderate.
Naming Consistency3/5
All tool names use snake_case and follow a verb_noun pattern, but the verbs are inconsistent: analyze, get, check, scan, audit, find, detect. This mix reduces predictability, though each name still clearly indicates its function (e.g., get_*_score, analyze_*, scan_*).
Tool Count3/5
With 28 tools, the suite is on the heavy side (above the 16-25 'heavy' range) but not excessive for a comprehensive code health system. Many tools exist in pairs (analysis vs. score), which inflates the count, but each serves a distinct purpose in providing both detailed results and quick summaries.
Completeness5/5
The suite covers a broad spectrum of code health aspects: complexity, dead code, security, imports, clones, test quality, type coverage, environment variables, naming, TODO debt, bugs, and docstrings. The full_health_check tool aggregates most analyses, ensuring no obvious gaps in the core health-check workflow.
Average 3.8/5 across 27 of 28 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. While 'scan' implies a read-only operation, the description does not state this explicitly, nor does it mention side effects, required permissions, output format, or performance implications. It only notes CWE mapping, which is a partial result indicator but not sufficient for full transparency.
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 consists of two concise sentences that front-load the purpose and list specific vulnerability types. No wasted words or redundant information. It is efficiently structured and immediately understandable.
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?
There is no output schema, so the description should explain what the tool returns. It mentions 'maps findings to CWE identifiers,' but does not clarify the output format (e.g., whether it returns a list, report, or score), or address error handling, performance, or special conditions. Given the tool's complexity (security scanning with multiple vulnerability types), this is incomplete.
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% (the single 'path' parameter is described as 'File or directory path to scan'). The description does not add further meaning beyond the schema; it simply refers to scanning Python code. Baseline 3 is appropriate when the schema already documents the parameter adequately.
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 scans Python code for security vulnerabilities, enumerates specific vulnerability types (command injection, SQL injection, etc.), and mentions CWE mapping. This provides a specific verb+resource ('Scan Python code') and distinguishes it from sibling tools like get_security_score, which likely returns a score rather than conducting a scan.
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 does not mention get_security_score or other related tools, nor does it specify any exclusions or prerequisites. The purpose implies usage for security scanning, but explicit differentiation from siblings is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 nature of the analysis (read-only inspection of a dependency graph) and names the kinds of results to expect, which helps the agent understand it won't modify code. However, it doesn't mention potential performance concerns with large projects, whether it traverses nested directories automatically, or what happens if the path is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total: one states what it does, and one states a use case. Every word earns its place with no filler 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 single-parameter read-only analysis tool with no output schema, the description adequately covers purpose and general outputs. The gap is that it doesn't clarify whether this is a pure read operation (no annotations available) or describe how the returned metrics are formatted, so an agent must infer behavior from the output names.
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 path parameter. The description adds the context that this is the project root directory to analyze, which is slightly useful, but it doesn't elaborate on format (e.g., absolute vs relative) or whether the tool creates any artifacts.
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 function as analyzing a Python import dependency graph and lists the specific outputs it returns (module metrics, circular dependencies, orphan modules, hub modules, instability scores), which distinguishes it from sibling analysis tools like analyze_complexity or find_dead_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use to understand project architecture,' which provides a general context but no explicit guidance on when to choose this tool over alternatives like get_import_health or audit_dependencies. There is no mention of exclusions, prerequisites, or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the output (per-file metrics and coverage percentages) but does not mention side effects, limitations, or potential performance implications, though as a read-only analysis tool, this is acceptable.
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 efficiently conveys the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It explains the return value, but lacks details on recursion behavior, error handling, or prerequisites, though the basic output is covered.
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 single parameter 'path' is clearly described in the schema as a file or directory path, and the description reinforces this by mentioning per-file metrics, so no additional detail is needed.
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 analyzes Python type annotation coverage and lists specific aspects (function signatures, parameters, return types, Any usage, type: ignore comments), distinguishing it from other analysis tools.
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 mention when to use this tool over other analysis tools, lacking guidance on appropriate scenarios or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not explicitly state that the tool is read-only or that it does not modify files. While an audit inherently suggests non-destructive checks, this is not stated, and there is no mention of potential side effects, output format, or error conditions.
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, using two sentences to list the core audit checks and supported languages. There is no redundant information or fluff; every clause adds value. It is well-structured and front-loaded with the primary purpose.
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 (one parameter) and the description covers its main function and scope. However, it does not describe the output or return format, which might be important for an agent to know how to use the results. Since there is no output schema, the description should ideally clarify what the tool returns (e.g., a report, list of issues), but it remains silent on this.
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 single parameter 'path' is described as 'Project root directory,' which adds a useful clarification beyond the schema's type and required status (it specifies that the path must point to a directory, not a file). However, the description does not elaborate on how the path is used or any constraints (e.g., must exist). With 100% schema coverage, the baseline is 3; the minor addition keeps it at 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 purpose: to audit environment variable usage, listing four specific checks (undefined references, unused vars in .env, secrets in templates, missing .env.example entries). This verb-noun pairing ('Audit environment variable usage') is precise and distinguishes it from sibling tools focused on complexity, security, or testing.
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 by listing supported languages (Python, JavaScript, shell scripts) and the types of findings, but it does not explicitly state when to use this tool versus alternatives. An agent can infer that this tool is for env var audits, but there is no direct guidance on when to choose it over other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It mentions 'cross-module analysis' which is a useful behavioral trait, but it does not state whether the tool is read-only, what output format is returned, or any side effects. The description is better than a tautology but lacks depth—e.g., no mention of severity levels or how results are presented.
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 purpose and a key capability. It is front-loaded with the primary action and avoids unnecessary filler. Every word contributes to understanding 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?
Given the tool's complexity (static analysis with a path, category, and severity filter) and the absence of an output schema, the description should explain what the results look like or what constitutes 'unused'. It mentions cross-module analysis to reduce false positives, which is helpful, but it does not describe the output format, how severity is assigned, or any limitations. The description is adequate but leaves the agent guessing about the return value.
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%—all three parameters have descriptions in the schema. The tool description does not add any extra meaning beyond the schema, so it reaches the baseline of 3. However, it does not elaborate on how parameters interact (e.g., how min_severity filters results or how category combines with path), missing an opportunity to add value.
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: detecting unused imports, functions, variables, and arguments in Python code. It also mentions cross-module analysis to reduce false positives, which differentiates it from generic code analysis tools. The verb 'detect' plus the resource 'dead code' is specific and distinguishes it from siblings like analyze_complexity or security_scan.
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, no prerequisites, and no mention of scenarios where it is appropriate. It neither says 'use this when...' nor 'for X, use Y instead'. Given the many sibling tools, this lack of context leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It tells the user what it returns (score, grade, profile, top vulnerability rules) but does not disclose side effects, such as whether it performs intensive scanning, network access, or has any destructive potential. It only says it gets an overall health score, which implies read-only, but without explicit statement of safety, the agent cannot fully assess behavioral implications.
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 main output and its range, then a concise phrase about intended use. Every sentence earns its place, and there is no wasted wording. It is appropriately sized for a simple retriever tool.
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 (one integer input, no output schema, no annotations), and the description adequately explains the output (score, grade, profile, rules). However, it could benefit from clarifying edge cases like invalid paths or what 'top vulnerability rules' means, but given the simplicity, the provided context is sufficient. There is no output schema, but the description compensates by listing return components.
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% (only the 'path' parameter is described as 'Directory path to scan'). The description adds context about the tool's purpose but does not elaborate on the 'path' parameter beyond what the schema states. Baseline of 3 is appropriate because the schema is sufficient for a single parameter, and the description does not hinder understanding.
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 retrieves a security health score from 0 to 100, along with grade, profile, and top vulnerability rules, and positions it as a quick posture assessment. It is distinct from sibling tools like security_scan, which likely performs detailed scanning, and get_*_score siblings that focus on other 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 it's for a quick security assessment, but it does not explicitly state when to use it versus alternatives like security_scan or other score tools. There's no mention of when not to use it or which sibling tools are more appropriate for detailed security analysis. The brevity provides some contextual hint ('quick posture assessment') but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool reads git history, extracts changed files, and runs static analysis, implying read-only behavior. However, it does not explicitly state whether it modifies anything, performance implications, or any side effects. It provides moderate transparency but not full detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and directly to the point. It succinctly states the purpose, the actions taken, and the output. No redundant or vague language, making it easy for an agent to grasp the essentials quickly.
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 complexity (6 parameters, multiple analysis aspects), the description provides a good overview of what is returned and the general process. It does not explain edge cases or fail conditions, but for an audit tool this is often sufficient. The absence of an output schema is mitigated by describing the return structure (grades, findings, violations).
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% for all six parameters, each with a descriptive comment. The tool description adds no extra meaning beyond these comments. Per the baseline rule for high coverage, a score of 3 is appropriate, as the description does not enrich parameter understanding.
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: 'Audit recent git commits in a repository.' It further specifies actions (extracts changed files, runs static analysis for security and complexity) and outputs (per-commit grades, security findings, complexity violations), which distinguishes it from sibling tools like get_security_score or analyze_complexity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention scenarios where one would prefer this over running individual analysis tools or provide exclusions. The description implies usage for auditing commits, but lacks direct comparative or contextual instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool 'penalizes low-quality docstrings' and 'shows worst files', which gives insight into the scoring behavior. However, it does not explicitly state that the operation is read-only, does not modify files, or any permissions needed. For a scoring tool, the lack of explicit safety guarantees is a minor gap, but the behavioral description is reasonably informative.
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 primary action and result, and every sentence adds value. No fluff or repetition. It is well-structured and easy to parse.
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 (one parameter, no output schema), the description covers the essential aspects: what it does, what it measures, and that it shows worst files. It does not mention return format details (e.g., JSON structure), but the description already states 'score (0-100) with grade', which is sufficient for most uses. It could note limitations or edge cases, but for a health score tool, this is nearly 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?
Schema coverage is 100%, so the baseline is 3. The description only adds 'Measures what percentage...' which indirectly clarifies the path parameter but does not go beyond the schema's 'Directory path to audit.' It does not explain format, constraints, or what happens if path is invalid. Since the schema fully describes the parameter, the description adds minimal extra semantic value, so a 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 purpose: 'Get a docstring coverage health score (0-100) with grade.' It also specifies what it measures ('percentage of public entities have docstrings') and additional output ('Shows worst files'), distinguishing it from siblings like get_todo_score. The verb 'get' + resource 'docstring score' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like audit_docstrings or get_todo_score. There is no mention of 'use this for a quick health score' or 'use audit_docstrings for a detailed audit'. The intended context is only implied by the description, which is insufficient for an agent to differentiate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explains the formula and score interpretation, but does not state whether the operation is read-only, requires permissions, or produces side effects. For a getter it is likely safe, but that is not explicitly communicated.
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, then explains the metric and interpretation. Every sentence adds value; no redundancy or fluff. This is an exemplary concise structure.
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 annotations and no output schema, the description provides enough context: score range, metric definition, and interpretation. It could specify the return object structure (e.g., whether grade is a letter), but given the simplicity, it is sufficiently 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?
Schema description coverage is 100% (the only parameter 'path' is described as 'Git repository root path.'). The description adds no additional detail about the parameter, which aligns with the baseline of 3 for high coverage. No extra semantics are provided 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 clearly states the tool retrieves an overall hotspot health score (0-100) with a grade, and explains the underlying metric (churn × complexity). This distinguishes it from siblings like find_hotspots (which likely lists hotspots) and get_complexity_score (which focuses on complexity alone).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need a high-level hotspot health score, use this tool. However, it does not explicitly specify when to prefer this over similar tools (e.g., find_hotspots or get_complexity_score) or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It clearly explains output scope (0-100 score, grade) and what it measures (PEP 8 snake_case, CamelCase, UPPER_SNAKE_CASE), but it does not disclose behavior for invalid paths, whether it scans recursively, or any performance or read-only caveats.
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-loads the main output value, and uses no filler. Every detail supports tool selection: score range, grade, and the specific PEP 8 conventions measured.
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 one-parameter read-only scoring tool, the description provides sufficient context: it states the output type (score/grade) and the compliance rules measured. It does not need an output schema explanation, and the missing path-behavior details are minor for this 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 schema already fully describes the only parameter ('Directory path to check') with 100% coverage. The description adds no additional semantic meaning about the path parameter beyond what the schema provides, 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 uses a specific verb ('Get') with a clearly defined resource ('naming convention health score') and adds measurable detail (0-100, grade, PEP 8 categories). It distinguishes itself from sibling tools like check_naming by emphasizing the score-and-grade output rather than just checking naming.
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 implies use when a naming health score is needed, but it does not explain when to use this over the closely related sibling check_naming, nor does it state any exclusions or prerequisites. No explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It explains the scoring inputs (annotation completeness, Any usage, type: ignore density) and output range/grade, but it does not mention side effects, read-only behavior, performance implications, or limitations. The added context is useful 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 two concise sentences with no filler. The primary purpose is front-loaded in the first sentence, and the second sentence efficiently lists the three components being measured.
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 single-parameter scoring tool, the description is largely complete: it states the output format (0-100 with grade) and the measurement dimensions. The main gap is the lack of guidance around related sibling tools, but this is a minor issue 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% with the single parameter clearly described as 'File or directory path to analyze.' The description does not add parameter-specific meaning, but with full schema coverage, the baseline 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 uses a specific verb ('Get') and a clearly defined resource ('overall type coverage health score (0-100) with grade'). It further distinguishes this tool from sibling scoring tools by naming the exact metrics it computes: annotation completeness, Any usage, and type: ignore density.
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 states what the tool does but gives no guidance on when to use it versus alternatives. Sibling tools such as analyze_type_coverage and full_health_check may overlap, but no exclusions, prerequisites, or preference conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It details the return components (score, grade, classification, breakdown) but omits any side effects, prerequisites (e.g., file permissions), or limitations like whether the scan is recursive. It is informative 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?
Two sentences front-load the primary purpose and enumerate the key outputs without any filler. The structure is highly efficient and focused.
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 there is no output schema, the description does enumerate the major return elements (score, grade, classification, breakdown). However, it lacks explanation of grading criteria or the meaning of 'bug profile' categories, which may be ambiguous. It is adequate for a quick health check but not fully comprehensive.
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 only parameter 'path' is described in the schema as 'Directory path to scan.' The description adds no additional context about path format, validation, or expected behavior. Since schema coverage is 100%, the baseline 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?
Clearly states the tool retrieves a 'bug detection health score' with specific output components (grade, classification, breakdown). It distinguishes itself from sibling score tools like get_complexity_score and get_security_score by focusing on bug detection.
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?
Provides minimal usage context with the phrase 'Quick bug health check,' implying a fast assessment. However, it does not explicitly state when to prefer this tool over alternatives like detect_bugs or other score tools, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a key prerequisite (git repository) and the return format (hotspot scores, risk levels, churn/complexity breakdown). However, it does not indicate whether the operation is read-only (though 'Find' suggests this), potential performance implications, or error behavior (e.g., missing git history). It adds some value but leaves several behavioral aspects underexplained.
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 with the core purpose in the first sentence. Each subsequent sentence contributes essential context: the risk rationale, a prerequisite, and the output format. No wasted words 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?
For a relatively simple analysis tool with no output schema, the description provides sufficient context: it defines the criteria, explains the purpose, states a prerequisite, and lists the return components. It does not delve into algorithm details or edge cases, but these are not critical for tool selection. The absence of any mention of error conditions or limitations is a minor gap, but overall the description is complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all three parameters are well-documented in the schema (path, top, since_days). The tool description adds no additional parameter-level semantics beyond what the schema already provides. Per rubric, this is the baseline score of 3 when schema covers parameters fully.
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?
Description clearly states what the tool does: finds files with high git churn AND high complexity. The dash construction introduces the specific resource (files) and the criteria, and the second sentence explains why these are risky. This differentiates it from sibling tools like get_hotspot_score, which likely focuses on a single file rather than repository-wide identification.
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 mentions 'Requires a git repository' as a prerequisite and implies use for identifying riskiest files, but it does not explicitly state when to use this tool versus alternatives like get_hotspot_score or analyze_complexity. No exclusion criteria or when-not-to-use guidance is given, so usage context is implied but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the output (aggregate score, grade, commit count, security summary) but does not mention any potential side effects, limitations, or dependencies. It appears read-only but this is not explicitly disclosed.
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, using two straightforward sentences with no unnecessary details or repetition. It is well-structured and easy to parse.
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 two parameters, the description provides sufficient context about its purpose and return values. It does not explain how the score is calculated or what 'security summary' entails, but that may be acceptable for a quick-audit tool. Overall, it is almost 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 input schema already provides clear descriptions for both parameters (repo path and number of commits). The tool description adds no extra meaning beyond what the schema already covers, so it meets the baseline but does not enhance understanding.
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 gets a quick overall grade and score for recent commits in a repo, distinguishing it from sibling tools that focus on other aspects like complexity or security.
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 quick overall scoring but does not explicitly compare with alternative tools like full_health_check or other score-specific tools. No clear guidance on when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 correctly implies a read-only operation and mentions the optional git blame enrichment, but it does not explicitly state side effects, performance characteristics (beyond the 'slower' note in the schema), or any limitations. This is adequate but not exhaustive.
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, tightly packed with relevant details. It lists the tags, describes the output, and mentions the optional enrichment without any 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?
While there is no output schema and no annotations, the description covers the return structure and the main functionality. It lacks some contextual detail like sorting or pagination, but for a scan tool it is sufficiently complete for an agent to understand what to expect.
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 schema already documents all parameters. The description adds value by enumerating the detectable tags and describing the return fields (file, line, tag, severity, message), which goes beyond the schema's basic parameter 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 the tool scans for specific technical debt markers and returns structured details. It distinguishes itself from sibling tools like get_todo_score by focusing on raw scan results rather than aggregated scores.
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 provide explicit guidance on when to use this tool versus alternatives such as get_todo_score. While the purpose implies raw scanning, there is no statement about when to prefer it for detailed inspection or when to use scoring tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior and side effects. It states it returns metrics, but does not explicitly mention that it is read-only or non-mutating. It also lacks details on error handling (e.g., invalid path, no test files). The description gives a basic idea but is not fully transparent about limitations or risks.
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 clear sentences. It lists the analysis topics and the output format without any redundant information. The structure is efficient and to the point.
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 adequately conveys the core purpose and output for a simple analysis tool. However, it omits details such as the format of the grade, whether non-test files are considered, or how max_length influences the analysis. Given the tool's simplicity, it is acceptable but not fully comprehensive.
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%: both path and max_length are described in the schema. The description does not add any extra clarification beyond what the schema provides. Since the schema already explains parameters adequately, the baseline is 3, and the description does not enhance it further.
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: analyzing test suite quality with specific aspects like assertion density, test length, naming conventions, and magic numbers. It distinguishes itself from sibling tools (e.g., analyze_complexity, analyze_imports) by focusing specifically on test quality metrics and outputs a score and grade.
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 implies usage for evaluating test suites, but does not explicitly state when to use it over alternatives. However, the name and content make it clear it is for test code analysis, and sibling tools cover other aspects, so the context is sufficient. It could be improved by explicitly stating to use it for test code rather than production code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral burden. It states what the tool returns (per-function metrics and grades) and implies a non-mutating analysis, which is useful. It does not discuss edge cases or limitations, but the read-only nature is reasonably clear from 'Analyze' and the output description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and input scope, then a compact list of return metrics. Every word earns its place; no fluff or repetition of the schema.
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 4 parameters, no annotations, and no output schema, the description is fairly complete: it defines the input scope and enumerates the return values. It does not describe return formatting or edge cases, but the listed metrics provide enough context for an agent to select and invoke 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 all four parameters. The description adds context about what the metrics mean (cyclomatic, cognitive complexity, etc.), but it does not add parameter-specific semantics beyond what the schema provides. 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 clearly states the tool analyzes Python code complexity for a file or directory and lists specific per-function metrics (cyclomatic, cognitive, nesting, length, grades). This distinguishes it from sibling tools like get_complexity_score or find_hotspots, which target summary scores or hotspot detection.
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 clear target input context ('file or directory') and implies read-only analysis, but it does not explicitly say when to prefer this tool over siblings like get_complexity_score or find_hotspots. Usage context is implied rather than stated with alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 metrics and the analytical purpose, implying a read-only computation, but it does not describe the output format, return structure, or any side effects. This is adequate but leaves gaps about what exactly the agent will receive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences deliver the tool's purpose, the computed metrics, and the practical motivation. Every phrase carries meaning; there is 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?
Given a single parameter, no output schema, and no annotations, the description gives enough context to invoke the tool correctly and interpret its purpose. It could be improved by outlining the expected output shape, but the metric list makes the result semantics reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'path' parameter, and the schema already states it is the 'Project root directory.' The description adds no parameter-level detail, but with full 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Analyze') tied to a concrete resource ('module coupling metrics') and enumerates the exact metrics computed (Ca, Ce, instability, hub scores). It also states the analytical purpose ('identifies tightly-coupled modules that may resist change'), which clearly distinguishes it from siblings like analyze_complexity or analyze_imports.
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 a clear use context: identifying tightly-coupled modules that may resist change. It does not explicitly name alternatives or say when not to use this tool, but the intended scenario is evident enough for an agent to select it appropriately among the sibling analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that it 'Reads requirements.txt and/or pyproject.toml' and 'Returns per-dependency status, latest versions, and CVE/vulnerability details,' implying a read-only, non-mutating operation. However, it does not mention potential network calls or side effects, so it is not fully 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 concise and well-structured, with the main purpose front-loaded. It contains no unnecessary information and is easy to understand.
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 gives a good overview of what the tool does and what it returns, but not the exact output format. Since no output schema is provided, this is sufficient for a simple tool. It is complete enough for most use cases.
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 has one parameter (path) with a clear description, so schema coverage is 100%. The tool description does not add additional meaning beyond the schema, 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 purpose: 'Audit Python project dependencies for outdated packages and known vulnerabilities.' It is specific and distinct from the sibling tools, which focus on other aspects of code quality.
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 by stating what it does, but it does not explicitly mention when to use it or provide alternatives. It is clear enough that it is for dependency auditing, but there is no direct guidance on when to choose it over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral burden. It transparently states what is checked (public functions, methods, classes, modules), what constitutes an issue (missing or low-quality docstrings), and what is returned (per-entity coverage, missing docstrings, quality issues). It does not define 'low-quality' criteria or edge cases, but it gives a solid behavioral overview.
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 tool's core purpose and immediately followed by what it returns. There is no filler or repetition of schema information.
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 only one required parameter and no output schema, the description provides adequate contextual coverage: purpose, scope, and return content. It would be richer if it clarified how 'low-quality' is assessed or whether directory scans are recursive, but it is not incomplete 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 only parameter 'path' is fully described in the input schema as 'File or directory path to audit' (100% schema description coverage). The description adds no additional parameter-level semantics such as syntax, defaults, or examples, so the baseline score 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 ('Audit') with a clear resource ('Python docstring coverage and quality') and enumerates the exact entities checked: public functions, methods, classes, and modules. This differentiates it from the sibling get_docstring_score, which likely returns only a score rather than a detailed audit.
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 clearly implies that this tool should be used when you need docstring coverage and quality auditing, but it does not explicitly mention the closely related sibling get_docstring_score or state when to prefer one over the other. No alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It specifies what the tool detects (three naming violation types) and what it returns (violations with suggestions), enough to imply a read-only static analysis operation.
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 tight sentences: purpose, rule details, and return behavior. Every sentence adds value, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only linting tool with no output schema, the description explains the scope, accepted input concept, and return type. It could be more explicit about output shape, but the description is sufficiently complete for this complexity level.
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 only parameter, path, is fully described in the schema as 'File or directory path to check.' The tool description does not add further parameter semantics, so the baseline of 3 applies given 100% schema coverage.
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?
Description clearly states it checks Python naming conventions against PEP 8 and enumerates specific rule categories (snake_case, CamelCase, UPPER_SNAKE_CASE). This distinguishes it from sibling get_naming_score, which likely summarizes a score rather than returning detailed violations.
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?
Use case is implied: run this when you need to detect naming violations. However, no explicit mention of when not to use it or how it differs from get_naming_score, which is directly relevant among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the transparency burden. It adds valuable context by specifying the 8 bug categories, giving an example (datetime.now()) for call-expression defaults, and asserting that findings are 'likely real bugs, not style violations'. This goes beyond a generic 'detect bugs' statement. However, it does not mention return format or side effects, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and includes the essential list of categories without verbosity. Every word adds value, achieving excellent conciseness and structure.
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 3 parameters and 8 bug categories, the description covers purpose, methodology, and the 'real bug' guarantee. It implies that findings are returned but does not specify the output format, which is a slight gap. Overall, it's largely complete given the schema richness.
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 parameters are well documented in the input schema. The tool description adds some value by enumerating the rule options and providing an example for one rule, but it doesn't clarify parameter usage beyond what the schema already states. Baseline of 3 is appropriate for high schema coverage.
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 detects common Python semantic bugs using AST analysis, and lists the 8 specific bug categories. This distinct purpose separates it from sibling tools like find_dead_code or security_scan.
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 when to use it (for semantic bug detection) but provides no explicit guidance on when not to use it or how it differs from alternatives like find_dead_code. It lacks any mention of alternative tools or exclusions, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 what the tool does and returns, but does not mention side effects (likely read-only), performance implications, or limitations beyond Python scope. It adds useful detail about clone types but lacks deeper behavioral context like recursion behavior or potential resource usage.
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 each sentence adds distinct information without repetition. It is efficiently written with no 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?
Given the tool's complexity and absence of an output schema, the description adequately conveys what the tool does, what it detects, and what it returns. It mentions cluster analysis and similarity scores, giving a reasonable picture. It lacks details on expected runtime or limitations on large projects, but these are not critical for basic selection.
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%, with each parameter described. The description does not add additional meaning to path, min_lines, or threshold beyond the schema, so it provides minimum baseline value. It does not clarify edge cases like how threshold interacts with type-3 clones.
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 detects code clones in Python projects, specifies clone types (Type-1/2/3), and mentions output (clone pairs with similarity scores and cluster analysis). It is distinct from sibling tools like find_dead_code or analyze_complexity, which target different code issues.
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 (detects duplicate code blocks) and implies when to use it (when code duplication is a concern), but it does not explicitly exclude alternatives or mention when not to use it. The scope is clear enough for an agent to choose it over unrelated analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read-only operation by using 'Get' but does not explicitly state side effects, permissions, or any behavioral traits.
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 unnecessary words; the second sentence 'Quick project health check' adds a minor context but is concise.
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, the description covers the main purpose and output (score, grade, classification, offenders) but does not mention any limitations or prerequisites; however, given the simplicity, it is adequate.
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 parameter 'path' is clearly described as 'Directory path to analyze', providing sufficient meaning beyond just the type.
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 it provides a complexity health score, letter grade, classification, and top offenders, distinguishing it from sibling tools like get_security_score.
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 does not explicitly specify when to use this tool over others; it only says 'Quick project health check' which is generic. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and reveals the key output behavior: a 0-100 score, a grade, and hotspot files. It also implies a read-only operation through 'Get' and clarifies the scoring criteria, though it does not disclose exact grade thresholds or output formatting.
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 focused sentences with the primary purpose and scoring basis front-loaded in the first sentence. The second sentence adds the hotspot file output without redundancy, making it efficient and well-structured.
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 single-parameter scoring tool, the description is adequately complete: it defines the score range, grading basis, and output features. It lacks exact grade thresholds and a formal output schema, but the combination of description and schema is sufficient for an agent to invoke 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?
The schema already documents the only parameter ('path') with 100% description coverage, so the description does not need to add much. However, it adds no extra detail about path format, recursion, or supported file types beyond what the schema provides, meeting the baseline but not exceeding it.
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 ('Get') and resource ('technical debt health score'), and distinguishes itself from sibling tools by naming the exact markers (TODO/FIXME/HACK) and the scoring basis (density and severity). It also notes the additional output of hotspot files, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when a quantitative health score is needed, but it does not explicitly contrast it with alternatives like scan_todos or get_hotspot_score. There is no 'when to use this instead of...' guidance, leaving the agent to infer the tool's role from its name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparently discloses the tool's scope, what it returns, and why certain analyses are excluded. It does not mention potential performance/resource implications or explicitly state that it is read-only, but the nature of 'analyses' on a project strongly implies non-destructive behavior, and the exclusions add meaningful context.
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 dense sentence listing all analyses, followed by a clear note about exclusions. It is front-loaded with the core purpose and the list is informative, though slightly overstuffed with parenthetical items. Still, every part earns its place and there is no waste.
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 parameter and no output schema, the description is quite complete: it lists the analyses, what the report contains, and explicitly excludes analyses that require extra context. It does not describe error handling or non-Python projects, but these 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 schema already describes the only parameter ('Directory path to analyze') with 100% coverage. The description adds the context that the path should point to a Python project, but does not provide syntax, format, or behavioral details beyond the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists all analyses performed (complexity, dead code, security, etc.) and states the output (combined health report with scores, grades, top issues). It clearly distinguishes itself from the many sibling tools by being an all-in-one scan rather than a single-analysis tool.
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 note about hotspot, dependency, and change impact requiring additional context (git repo, requirements files, changed files) provides clear insight into when this tool is NOT sufficient and implicitly signals to use sibling tools for those analyses. However, it doesn't explicitly say 'use this instead of running individual analysis tools when you need a full overview', making the guidance slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does disclose what the score penalizes (circular dependencies, orphan modules, unstable modules, hub concentration) and implies a read-only operation via 'health check.' It does not explicitly state side effects or limitations, but for a scoring tool this is sufficient context beyond the obvious. Given no annotations, this is a solid disclosure but not exhaustive.
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 primary result (score and grade), and immediately lists key scoring factors. Zero filler or redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one param, no output schema) and the 'quick check' framing, the description covers the essential functionality: what it returns, what it penalizes, and its quickness. It does not detail how the score is calculated or what 'grade' means, but for a quick health check, this is adequate. With no output schema, a bit more detail on the grade scale could improve completeness, but overall it is sufficient.
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%—the only parameter 'path' is fully documented as 'Root directory to analyze.' The description adds no additional semantic meaning about the parameter beyond what the schema already provides. With full schema coverage, baseline 3 is appropriate, and the description does not elevate it further.
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: 'Get an import graph health score (0-100) with grade.' It specifies the resource (import graph) and the action (get health score), and distinguishes itself from sibling score tools by listing specific penalties (circular dependencies, orphan modules, etc.). This is a specific verb+resource that differentiates it from similar tools like get_complexity_score.
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 phrase 'Quick architecture health check' provides clear context for when to use the tool—when a fast, high-level assessment of import graph health is needed. However, it does not explicitly mention alternatives or exclusions (e.g., when to use analyze_imports for deeper analysis). This is clear context without explicit when-not usage, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's behavior by listing the types of information it returns (direct dependents, transitive impact, affected tests, impact score) and the metric (fraction of project affected). While there are no annotations, this explicit disclosure covers the main behavioral aspects, though it omits details like output format or error handling.
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, using only two sentences to convey the purpose, outputs, and usage. No redundant information is present, and every sentence 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 complete overview of what the tool does and the key outputs, which suffices for the given context. It does not formally document the output schema, but the description implies the return structure (direct dependents, transitive impact, etc.). This is adequate for a tool with no output schema defined.
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?
Each parameter has a description: path (project root), max_depth (max transitive dependency depth), and changed_files (list of files relative to root). The descriptions are clear and cover the purpose, but they do not elaborate on constraints like file format or required syntax, which is minor given the simplicity.
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: analyzing the ripple effect of changing files. It specifies the resource (files) and the action (analyze change impact), distinguishing it from sibling tools that focus on other metrics like complexity or dead code.
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 a clear usage context ('Use before refactoring to understand blast radius') and hints at the output (direct dependents, transitive impact, affected tests, impact score). However, it does not explicitly mention when not to use this tool versus alternatives, but the context is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![code-health-suite MCP server](https://glama.ai/mcp/servers/neogeweb3/code-health-suite/badges/card.svg)](https://glama.ai/mcp/servers/neogeweb3/code-health-suite)

Score Badge

Copy to your README.md:

[![code-health-suite MCP server](https://glama.ai/mcp/servers/neogeweb3/code-health-suite/badges/score.svg)](https://glama.ai/mcp/servers/neogeweb3/code-health-suite)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/neogeweb3/code-health-suite'

If you have feedback or need assistance with the MCP directory API, please join our Discord server