Skip to main content
Glama

CodeVitals

npm version CI license node

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/.gitignore checks, 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/codevitals

Or run it without installing:

npx @prakhhxrcodes/codevitals

From source

git clone https://github.com/prakharsharma13/codevitals.git
cd codevitals
npm install
npm run build

CLI Usage

CodeVitals ships a single executable, codevitals, that launches the MCP server over stdio:

codevitals

The 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/codevitals

Verify:

claude mcp list

You should see CodeVitals connected.

Restart Claude Code if needed and check:

/mcp

Using a global installation

First install:

npm install -g @prakhhxrcodes/codevitals

Then:

claude mcp add codevitals --scope user -- codevitals

Verify:

claude mcp list

Restart Claude Code and check:

/mcp

You 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

repositoryPath

string

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.ts assembles the application; dependencies.ts constructs 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/  # helpers

Contributing

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 tools
analyze_repositoryAnalyze RepositoryB

Analyzes a repository and returns metadata, a health score, and a summary.

ParametersJSON Schema
NameRequiredDescriptionDefault
repositoryPathYesAbsolute path to the repository to analyze.

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/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 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.

Parameters3/5

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.

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 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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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

The description implies the tool is 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.

  1. 2 tool updatesv0.1.0
    • First observedanalyze_repository
    • First observedhealth_check

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

health_check and analyze_repository are clearly distinct: one checks server status, the other performs repository analysis. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (health_check, analyze_repository), making the naming predictable and uniform.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers