CodeVitals
This server provides repository health analysis through two synchronous, offline tools that do not use LLMs:
health_check: Verifies the server is running and responsive; no inputs required.
analyze_repository: Analyzes a local repository given its absolute path and returns a JSON report containing:
Repository metadata (dependency counts, framework, Git status, file/directory/line counts, project type, package manager, language, Docker/CI/test setup).
A weighted health score (0–100) with sub-scores for security, dependency, maintainability, and architecture.
Security analysis (sensitive file detection,
.env/.gitignorechecks, hardcoded secret scanning).Dependency health (duplicate, unused, and unpinned dependencies).
Dead code detection (unused/orphan files, empty directories, large files).
Code quality warnings (large functions, deep folder structures, naming issues).
A deterministic human-readable summary of strengths, weaknesses, warnings, and quick wins.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@CodeVitalsCan you run a health check on /Users/alice/projects/myapp?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CodeVitals
AI-powered Repository Health Analysis & Project Intelligence MCP Server.
Overview
CodeVitals is a Model Context Protocol (MCP) server that inspects a local repository and reports its metadata, a weighted health score, and a human-readable summary — entirely offline, with no external API calls. It is designed to be spawned by an MCP-compatible client (such as an AI assistant) and communicates over stdio.
Related MCP server: RepoCrunch
Features
Repository analysis — dependency counts, framework detection, git status, and file metrics.
Architecture detection — project type, package manager, language, Docker, CI, and test setup.
Security analysis — sensitive files,
.env/.gitignorechecks, and hardcoded-secret scanning.Dependency health — duplicate, unused, and unpinned dependency detection.
Dead code detection — unused files, orphan files, empty directories, and large files.
Code quality — file-size distribution, large-function, deep-folder, and naming warnings.
Health score — a weighted 0–100 score across security, architecture, dependencies, maintainability, and metrics.
Deterministic summary — strengths, weaknesses, warnings, and quick wins. No LLM involved.
Requirements
Node.js >= 20
Installation
Install globally:
npm install -g @prakhhxrcodes/codevitalsOr run it without installing:
npx @prakhhxrcodes/codevitalsFrom source
git clone https://github.com/prakharsharma13/codevitals.git
cd codevitals
npm install
npm run buildCLI Usage
CodeVitals ships a single executable, codevitals, that launches the MCP server
over stdio:
codevitalsThe process is not an interactive command-line tool — it does not take subcommands or arguments. It starts a server that waits for an MCP client to connect over stdin/stdout. Running it directly in a terminal is mainly useful for verifying that it starts (it prints a startup message to stderr and then waits). In normal use it is launched automatically by an MCP client (see below).
MCP Usage
Register CodeVitals with any MCP-compatible client.
Using npx (no installation required):
{
"mcpServers": {
"codevitals": {
"command": "npx",
"args": ["@prakhhxrcodes/codevitals"]
}
}
}Installed globally — use this when CodeVitals has been installed with
npm install -g @prakhhxrcodes/codevitals and the codevitals CLI is available
on your PATH:
{
"mcpServers": {
"codevitals": {
"command": "codevitals"
}
}
}If installed from source, point the client at the built entry file instead:
{
"mcpServers": {
"codevitals": {
"command": "node",
"args": ["/absolute/path/to/codevitals/dist/index.js"]
}
}
}Claude Code
Using npx
claude mcp add codevitals --scope user -- npx -y @prakhhxrcodes/codevitalsVerify:
claude mcp listYou should see CodeVitals connected.
Restart Claude Code if needed and check:
/mcpUsing a global installation
First install:
npm install -g @prakhhxrcodes/codevitalsThen:
claude mcp add codevitals --scope user -- codevitalsVerify:
claude mcp listRestart Claude Code and check:
/mcpYou should see the health_check and analyze_repository tools available.
Tools
health_check
Checks whether the CodeVitals MCP server is running. No input.
analyze_repository
Analyzes a repository and returns its metadata, health score, and summary.
Field | Type | Description |
|
| Absolute path to the repository to scan. |
Configuration
CodeVitals requires no environment variables or configuration files. Analysis
thresholds (for example, the large-file and deep-folder limits used by the
dead-code and code-quality analyzers) ship with sensible defaults defined in
their respective analyzers. The only per-call input is repositoryPath, passed
to the analyze_repository tool.
Example Outputs
analyze_repository returns a JSON document combining three sections:
{
"analysis": {
"dependencyCount": 2,
"devDependencyCount": 2,
"framework": "Unknown",
"isGitRepository": false,
"commitCount": 0,
"totalFiles": 45,
"totalDirectories": 9,
"totalLines": 3290,
"projectType": "Node",
"packageManager": "npm",
"language": "TypeScript",
"hasDocker": false,
"hasCI": false,
"hasTests": false
},
"health": {
"overallScore": 86,
"securityScore": 100,
"dependencyScore": 100,
"maintainabilityScore": 97,
"architectureScore": 35,
"summary": "Repository health: Excellent (86/100)."
},
"summary": {
"strengths": ["Uses TypeScript.", "Security risk is Low."],
"weaknesses": ["Missing Docker support.", "CI/CD pipeline not configured."],
"warnings": [],
"quickWins": ["Add a Dockerfile.", "Add a CI workflow."],
"overallSummary": "Repository scored 86/100. Security risk is Low."
}
}Architecture
CodeVitals follows a strict layered architecture with constructor dependency injection and a single composition root:
index.ts— bootstraps the process: creates the server, wires the stdio transport, and connects.server/—create-server.tsassembles the application;dependencies.tsconstructs every dependency.tools/— MCP tool registration only; the sole layer aware of the MCP SDK.services/— orchestration and scoring; coordinate analyzers without doing I/O.analyzers/— pure analysis logic; never import the MCP SDK.infrastructure/— filesystem, git, and scanning; no business logic.types/,utils/,constants/— shared, dependency-free helpers.
Dependencies always point inward: tools → services → analyzers → infrastructure. Analyzers and infrastructure never depend on the MCP layer.
Folder Structure
src/
index.ts # entry point (stdio transport)
server/ # server assembly + dependency wiring
tools/ # MCP tool registration
services/ # orchestration + scoring + summary
analyzers/ # analysis logic
infrastructure/ # filesystem, git, scanning
types/ # shared interfaces
utils/, constants/ # helpersContributing
Contributions are welcome. See CONTRIBUTING.md for setup and
guidelines. Please make sure npm run build and npm run typecheck pass before
opening a pull request.
FAQ
Does CodeVitals send my code anywhere? No. All analysis runs locally. There are no network or external API calls.
Does it require an API key or an LLM? No. The health score and summary are fully deterministic.
Which languages does it analyze?
It targets JavaScript/TypeScript projects (it reads package.json and scans
common source extensions), but file, git, and structural metrics apply to any
repository.
Can I run it as a standalone CLI report? Not yet — it currently runs as an MCP server. A standalone reporting mode is on the roadmap.
Troubleshooting
The server starts and then exits immediately. That is expected when it is run directly without an MCP client: with no client attached to stdin, the stdio transport reaches end-of-input and shuts down. Run it through an MCP client instead.
analyze_repository returns an error.
Ensure repositoryPath is an absolute path to a directory that contains a
package.json. The tool returns a descriptive error message when the path is
missing or unreadable.
npm error code E404 when installing or running the package.
npm could not find the package in the registry. Check that the package name is
spelled correctly (including the @prakhhxrcodes/ scope), that you are pointed
at the public npm registry, and that the version you requested has actually been
published.
npm warn EBADENGINE / npm error code EBADENGINE.
Your Node.js version does not satisfy the package's engines requirement.
CodeVitals requires Node.js >= 20 — check your version with node -v and
upgrade if it is older.
Roadmap
Standalone CLI reporting mode
HTML / PDF report output
GitHub integration
npm registry integration for outdated-dependency checks
AI-generated insights
Plugin system for custom analyzers
License
MIT © Prakhar Sharma
Available Tools
2 toolsanalyze_repositoryAnalyze RepositoryB
Analyzes a repository and returns metadata, a health score, and a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| repositoryPath | Yes | Absolute path to the repository to analyze. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure, but it only lists outputs. It does not state whether the tool is read-only, modifies the repository, has side effects, or requires specific permissions. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently states the tool's core function and deliverables. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 basic input and output. However, it omits important contextual guidance such as when to use this over 'health_check', and does not clarify potential side effects or prerequisites. This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the 'repositoryPath' parameter with a clear description ('Absolute path to the repository to analyze'). The tool description adds no additional semantic detail beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Analyzes a repository') and its outputs ('metadata, a health score, and a summary'). It also differentiates from the sibling tool 'health_check' by covering a broader scope than just health, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus the sibling 'health_check', nor any exclusions or alternative tools. The context signal of a sibling tool is ignored.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkHealth CheckA
Checks whether the CodeVitals MCP server is running.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 clearly states the tool performs a read-only check of server status, which is transparent and accurate. It does not detail the return format, but for a health check the behavior is sufficiently disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fully explains the tool's purpose without unnecessary words. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters and no output schema, the description is adequately complete. It could mention the expected return value (e.g., status object), but the given context makes the tool's function clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details because there are none to document; the schema confirms this. This is appropriate for a no-input tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('checks') and clearly names the target resource ('CodeVitals MCP server'), making the tool's purpose unmistakable. It implicitly distinguishes from the sibling analyze_repository, which has a different function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to verify server availability before performing other operations, but it does not explicitly state when or when not to use it. No alternatives are mentioned, though none are needed for a health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
analyze_repository - First observed
health_check
TDQS
Scored across 2 tools
health_check and analyze_repository are clearly distinct: one checks server status, the other performs repository analysis. There is no overlap or ambiguity.
Both tools follow a consistent verb_noun pattern (health_check, analyze_repository), making the naming predictable and uniform.
With only 2 tools, the set feels thin. However, the scope is narrow and focused on repository analysis, so it is borderline rather than severely lacking.
The server covers its core purpose with a health check and a repository analysis tool. The analysis tool provides metadata, health score, and summary, leaving no obvious dead ends for basic usage, though deeper analysis features are absent.
Maintenance
Related MCP Connectors
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Related MCP Servers
- FlicenseAqualityCmaintenanceA deterministic, network-free MCP server for validating repository release hygiene and version alignment in local projects. It enables automated repository health checks and generates standardized release checklists based on project state.1-
- AlicenseNot gradedqualityCmaintenanceAnalyze GitHub repositories into structured JSON with tech stack detection, dependency analysis, health signals, and security checks. No AI, fully deterministic. Available as CLI and MCP server.9MIT
- AlicenseBqualityCmaintenanceAnalyze GitHub repositories with health scores, issue triage, and action items through MCP tools.4MIT

repo-doctorofficial
AlicenseNot gradedqualityCmaintenanceMCP server that produces scored, evidence-cited audits of public GitHub repos via tools for fetching metadata, reading files, scanning git history, and checking hygiene.MIT