code-quality-mcp

by zoharazr

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
analyze_project and check_quality overlap in purpose, both analyzing project type and quality. The get_recommendations, get_smart_summary, and get_quick_wins tools are related but distinct in output style, so disambiguation is moderate.
Naming Consistency5/5
All tool names consistently follow a verb_noun pattern (analyze_project, check_quality, get_recommendations, etc.). The use of get_ for most retrieval functions is uniform and predictable.
Tool Count5/5
Six tools is within the ideal 3-15 range for a focused code-quality server. Each tool addresses a specific aspect of the domain without bloat.
Completeness4/5
The tool set covers analysis, quality checking, recommendations, summaries, quick wins, and trends, providing a comprehensive view of code quality. Missing a raw issue list or fix application is a minor gap, but agents can work around it via the existing tools.
Average 3.2/5 across 6 of 6 tools scored.
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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 bears full responsibility for behavioral disclosure. It states what the tool does but does not mention return format, side effects, permissions, or the effect of the 'deep' parameter, leaving the agent without important context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of overlapping sibling tools, the description is too terse. It lacks information about what the analysis returns, how deep analysis differs, and when to choose this tool over alternatives like check_quality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both projectPath and deep, covering 100% of parameters. The description adds no extra meaning beyond what the schema states, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes project type and code quality, using a specific verb and resource. It distinguishes from siblings like check_quality by also covering project type, though the scope could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use analyze_project versus sibling tools such as check_quality or get_recommendations. The description does not mention any exclusions or preferred contexts.
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, the description carries the full burden of behavioral disclosure. It only says 'Check code quality' and mentions modes, but does not disclose whether the tool is read-only, what it returns, or that certain checks (security/complexity) require deep analysis—a key behavioral constraint. This is insufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and then providing mode information. Every word earns its place; it is concise and well-structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool with 9 parameters, no output schema, and no annotations. The description does not mention the return format, pagination behavior, or how it relates to sibling tools like analyze_project. Given the lack of an output schema, the description should explain what the tool returns, but it omits that entirely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's mention of 'fast (logic-based) and deep (AI-powered) analysis modes' loosely maps to aiEnabled and deepAnalysis, but adds minimal new meaning beyond what the schema already describes. No parameter-specific details are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Check code quality') and a resource ('project type'), giving a clear sense of the tool's purpose. However, it does not explicitly distinguish itself from sibling tools like analyze_project, which could serve a similar function, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two modes (fast and deep) but provides no guidance on when to use this tool compared to alternatives like analyze_project or get_recommendations. There is no explicit context for selecting check_quality over its siblings, leaving the agent without decision-making guidance.
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 fully communicate behavioral traits, but it only states 'Get code quality recommendations'. It does not disclose whether the operation is read-only, safe, or what the response structure looks like, leaving a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the key action. It wastes no words, but it is arguably too sparse, lacking depth that would make it more useful. Still, for a simple tool, the conciseness is acceptable.
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?
With no output schema and no annotations, the description should compensate by explaining what 'code quality recommendations' means, how they are generated, or how this tool differs from siblings. It does none of these, making the tool underspecified.
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 describes both parameters (projectPath with 'Path to the project' and language with 'Language for recommendations (en/he)'), so schema coverage is 100%. The description adds no new parameter context, but the schema fully carries the load, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('Get') and resource ('code quality recommendations'), making the tool's action understandable. However, it does not distinguish this tool from sibling tools like check_quality or get_quick_wins, so it stays at the 'clear but no sibling differentiation' level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description is a bare one-liner without any contextual cues, exclusions, or mention of preferred 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 the full burden of disclosing behavior. It states the tool returns a 'concise, actionable summary' but does not describe the output format, whether it is a read-only operation, how the summary is generated, or any side effects. This leaves significant behavioral ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and includes a useful qualifier ('instead of full issue list'). No wasted words; it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description adequately conveys the basic purpose for selection but lacks details about return value structure and edge cases. Given the simplicity, it is minimally complete but not rich enough to fully inform an agent about expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter descriptions (projectPath is described as 'Path to the project'). The description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'concise, actionable summary of code quality', which is a specific verb and resource. It differentiates from a 'full issue list' but does not explicitly name sibling tools, leaving some ambiguity among get_recommendations, get_quick_wins, and get_trends. Thus it is clear but not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'instead of full issue list' implies the tool should be used when a summary is preferred over a detailed list, which is useful context. However, no explicit when-to-use versus alternatives are given, and sibling tools like get_recommendations or get_quick_wins are not mentioned. Usage guidance is primarily implied.
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 carries the full burden of behavioral disclosure. It only characterizes the output as 'high-impact, low-effort fixes' but does not state whether the tool is read-only, whether it modifies code, or what side effects might occur. It also omits any details about permissions, rate limits, or destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It earns its place by stating the tool's purpose and value proposition concisely.
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 is mostly complete. It communicates the purpose and intended outcome. However, it could benefit from noting that the tool is a read-only analysis or indicating the expected response format, but this is not critical for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since 'projectPath' is described as 'Path to the project'. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate. No extra parameter nuances are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves high-impact, low-effort fixes aimed at improving code quality. It uses the verb 'Get' and identifies the resource (fixes) and purpose, which distinguishes it from siblings that analyze or summarize. However, it doesn't explicitly differentiate from 'get_recommendations', which may overlap.
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 one wants quick code quality improvements but provides no explicit when-to-use or when-not-to-use guidance relative to sibling tools. There are no alternatives named or exclusions stated, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of explaining the tool's behavior. It only states the general purpose and does not disclose whether the operation is read-only, what data source is used, how the output is structured, or any limitations. This lack of transparency leaves the agent guessing about side effects or expectations.
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, succinct sentence that is front-loaded with the key action and resource. Every word earns its place, and there is no redundancy or filler.
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?
As a simple tool with one parameter and no output schema, the description provides the essential purpose but leaves gaps: it does not indicate the nature of the output (e.g., a report, chart, or list), the time range covered, or any prerequisites. For a tool of this complexity, a bit more context would improve completeness, but it is not severely deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, projectPath, with a clear description ('Path to the project'). Since schema coverage is 100%, the schema fully documents the parameter. The description adds no additional semantic detail, which is acceptable at the baseline for high 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 uses a specific verb ('See') and clearly identifies the resource and scope: code quality trends over time. It distinguishes itself from sibling tools like check_quality or get_quick_wins by focusing on temporal progression, making its purpose unmistakable.
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 tracking how code quality changes over time, which suggests using this tool when historical context is needed rather than a one-time snapshot. However, it does not explicitly name alternatives or provide exclusions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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-quality-mcp MCP server](https://glama.ai/mcp/servers/zoharazr/code-quality-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zoharazr/code-quality-mcp)

Score Badge

Copy to your README.md:

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

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/zoharazr/code-quality-mcp'

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