Skip to main content
Glama
Sign In
CodeHealth MCP Server

CodeHealth MCP Server

by microbrewerGM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

code_health_score

Score a single source file for maintainability to get a quick health check before or after editing, returning a 1–10 score and category.

Instructions

Score one source file for maintainability.

When to use: a quick health check of a file before or after editing it.
Limitations: one file at a time; some smells need a tree-sitter adapter
(Python, JS, TS/TSX, Java, Go) or PMD, see the analyzers field.
Returns: {path, language, score 1-10, category, optimal, analyzers}.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_path": "<file_path>"
    },
    "name": "code_health_score"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the one-file-at-a-time limit and warns that some smells require a tree-sitter adapter (Python, JS, TS/TSX, Java, Go) or PMD, pointing to the analyzers field for what actually ran. It does not state error behavior for unsupported languages or missing files, which is the main remaining 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?

Labeled sections (When to use, Limitations, Returns) front-load the essentials in a few short lines with no filler. The Returns line slightly duplicates the existing output schema, but it is a compact and useful orientation.

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

Completeness4/5

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

For a one-parameter scoring tool with an output schema present, the definition covers trigger, scope limits, analyzer caveats, and the return shape, which is close to everything an agent needs. Missing only failure-mode guidance and an explicit contrast with the multi-file review sibling.

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 0% for the single file_path parameter, so the description must compensate. It clarifies the input is one source file and that language support is bounded by adapters, but it never says whether the path must be absolute, repo-relative, or what happens to non-source files.

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?

"Score one source file for maintainability" gives a specific verb (score) and resource (source file) and pins the scope to a single file, which implicitly separates it from the review/change-set siblings. It stops short of naming an explicit alternative, so an agent still has to infer the boundary against code_health_review.

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 "When to use" line gives a concrete trigger: a quick health check of a file before or after editing. That is clear context, but it offers no explicit exclusions or pointer to the sibling that should be used for multi-file or change-set checks.

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

Deploy Server

Other Tools