What can you do with this server?

MCP Code Sanitizer is an AI-powered code review and analysis server that integrates with Claude, Cursor, VS Code, and GitHub Actions to find bugs, vulnerabilities, and security issues in your code. * analyze_code — Strictly review a code fragment for bugs, security vulnerabilities, and code quality issues, returning a score (0–100) with categorized issues, warnings, and suggestions. * compare_code — Compare two versions of code to detect regressions, improvements, or neutral changes, with a merge/request_changes recommendation. * explain_code — Generate a step-by-step explanation of code, tailored to a junior, middle, or senior audience. * generate_tests — Automatically create unit tests (pytest, jest, go test, etc.) covering happy paths, edge cases, and security scenarios. * analyze_file — Analyze an entire file from disk, with automatic language detection by extension and parallel chunking for large files. * generate_report — Convert any analysis result into a formatted HTML report, optionally saved to a specified path. * cache_info — View cache statistics (hit rate, entry count, etc.) or clear the cache entirely.

Which integrations are available for this server?

Generates Jest test cases with happy path, edge cases, and security tests. Generates pytest test cases with happy path, edge cases, and security tests.

de en es ja ko ru zh

MCP Code Sanitizer

by notasandy

Overview Schema Related Servers Score Discussions

Python

mcp-code-sanitizer

Strict AI-powered code reviewer for Claude Desktop, Cursor, VS Code, and Claude Code CLI. Finds bugs, vulnerabilities, and security issues — powered by Groq (free API).

Python PyPI FastMCP Groq License

Claude / Cursor / VS Code  ──MCP──►  code-sanitizer  ──REST──►  Groq API
                                        (server.py)              (llama-3.3-70b)

demo

Features

Tool	What it does
`analyze_code`	Strict review — bugs, security issues, score 0–100
`compare_code`	Compares two versions, detects regressions, recommends merge/request_changes
`explain_code`	Step-by-step explanation for junior / middle / senior audience
`generate_tests`	Generates pytest / jest / go test — happy path, edge cases, security
`analyze_file`	Analyzes a whole file from disk with parallel chunking
`generate_report`	Builds an HTML report from any analysis result
`cache_info`	Cache statistics and clearing

Example output

{
  "summary": "Critical SQL injection and secret exposed in logs",
  "score": 23,
  "issues": [
    {
      "severity": "critical",
      "line": 2,
      "title": "SQL Injection",
      "description": "f-string directly interpolates user_id into query",
      "fix": "cursor.execute('SELECT * FROM users WHERE id = %s', (user_id,))"
    }
  ],
  "warnings": [{"title": "No exception handling", "description": "..."}],
  "suggestions": ["Consider using an ORM instead of raw SQL"]
}

Related MCP server: Claude Code Review MCP

Installation

Prerequisite: Get a free Groq API key at console.groq.com/keys — no credit card required.

Claude Code CLI

claude mcp add code-sanitizer -e GROQ_API_KEY=gsk_your_key -- uvx mcp-code-sanitizer

Claude Desktop

OS	Config file
macOS	`~/Library/Application Support/Claude/claude_desktop_config.json`
Windows	`%APPDATA%\Claude\claude_desktop_config.json`
Linux	`~/.config/Claude/claude_desktop_config.json`

{
  "mcpServers": {
    "code-sanitizer": {
      "command": "uvx",
      "args": ["mcp-code-sanitizer"],
      "env": {
        "GROQ_API_KEY": "gsk_your_key_here"
      }
    }
  }
}

Cursor

Create .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):

{
  "mcpServers": {
    "code-sanitizer": {
      "command": "uvx",
      "args": ["mcp-code-sanitizer"],
      "env": {
        "GROQ_API_KEY": "gsk_your_key_here"
      }
    }
  }
}

VS Code

Requires VS Code 1.99+ with GitHub Copilot. Create .vscode/mcp.json in your project:

{
  "servers": {
    "code-sanitizer": {
      "command": "uvx",
      "args": ["mcp-code-sanitizer"],
      "env": {
        "GROQ_API_KEY": "gsk_your_key_here"
      }
    }
  }
}

Or add globally via Ctrl+Shift+P → "MCP: Add Server".

Don't have uvx? Install it with pip install uv, then use the commands above.

Manual install (alternative)

If you prefer cloning the repo:

git clone https://github.com/notasandy/mcp-code-sanitizer
cd mcp-code-sanitizer
pip install -r requirements.txt
cp .env.example .env   # add your GROQ_API_KEY
python server.py

Then point the client config to:

{
  "command": "python",
  "args": ["/full/path/to/server.py"],
  "env": { "GROQ_API_KEY": "gsk_your_key_here" }
}

GitHub Action — automatic PR review

Add AI code review to any repository in 5 lines. The action posts a structured comment on every PR with score, issues, and fix suggestions.

# .github/workflows/ai-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: notasandy/mcp-code-sanitizer@v1
        with:
          groq_api_key: ${{ secrets.GROQ_API_KEY }}

Add GROQ_API_KEY to your repository secrets → Settings → Secrets → Actions.

The action automatically:

Reviews only changed files (up to 10 per PR)
Posts a score and structured issue list as a PR comment
Fails the check if critical issues are found

Usage in chat

After connecting, just write naturally:

Review this code for vulnerabilities:

def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query)

Or call tools explicitly:

analyze_file /path/to/my_script.py
generate_tests for this function: ...
compare_code — before vs after refactor, did it get better?
generate_report and save to /tmp/report.html

Architecture

mcp-code-sanitizer/
├── server.py          # FastMCP entry point
├── config.py          # Constants — keys, limits, extension map
├── groq_client.py     # Async Groq client with auto-retry on 429
├── cache.py           # In-memory LRU cache with TTL
├── prompts.py         # System prompts for all tools
└── tools/
    ├── analyze.py     # analyze_code
    ├── compare.py     # compare_code
    ├── explain.py     # explain_code
    ├── tests.py       # generate_tests
    ├── file_tool.py   # analyze_file — chunking + parallel analysis
    ├── cache_tool.py  # cache_info
    └── report.py      # generate_report — HTML output

Configuration

All settings via .env or environment variables:

Variable	Default	Description
`GROQ_API_KEY`	—	Required. Get at console.groq.com
`GROQ_MODEL`	`llama-3.3-70b-versatile`	Groq model to use
`CACHE_TTL`	`3600`	Cache TTL in seconds
`CACHE_MAX`	`200`	Max cached entries

Available Groq models

Model	Speed	Quality
`llama-3.3-70b-versatile`	Fast	Best (default)
`llama-3.1-8b-instant`	Fastest	Good
`mixtral-8x7b-32768`	Fast	Great

Contributing

PRs and Issues are welcome. Most wanted:

Support for other LLM providers (OpenAI, Anthropic)
New tools: dependency audit, complexity score, docstring generator
Prompt improvements and new language support

License

MIT — do whatever you want. A star would be appreciated.

Available Tools

7 tools

analyze_codeC

Strict analysis of a code fragment using Groq LLM.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Code fragment to review.
`language`	No	Programming language (python, javascript, go, rust, ...).	python
`context`	No	Optional description - what the code does or where it came from.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It only mentions 'strict analysis' and 'Groq LLM', but does not disclose key behavioral traits such as whether it reads only, calls external APIs, has rate limits, or any side effects. The word 'strict' implies rigor but is vague.

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 immediately conveys the tool's core purpose. It is front-loaded and contains no extraneous information.

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 tool has 3 parameters and an output schema, the description is too sparse. It does not explain what 'strict analysis' entails, how the Groq LLM is used, or any constraints on the code fragment. An output schema exists but the description still lacks essential context for an agent to use it effectively.

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 baseline is 3. The description does not add meaning beyond the schema; it refers to 'code fragment' which matches the 'code' parameter, but does not elaborate on 'language' or 'context' parameters.

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 verb (analyze) and resource (code fragment), and specifies the method (using Groq LLM). It is distinct from siblings like 'analyze_file' by emphasizing code fragment analysis, but does not explicitly differentiate from 'explain_code' or 'compare_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?

No guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or scenarios where other tools like 'explain_code' or 'compare_code' would be more appropriate.

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

analyze_fileA

Analyzes a whole code file from disk. Automatically detects language by file extension. Large files are split into chunks and analyzed in parallel.

ParametersJSON Schema

Name	Required	Description
`file_path`	Yes	Absolute path to the file.
`language`	No	Language override (auto-detected from extension if not set).
`context`	No	Description of what the file does (optional).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses automatic language detection and parallel chunking for large files—key behaviors beyond the obvious. However, it omits potential side effects (e.g., read-only guarantee) and 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?

Three concise sentences, front-loaded with purpose, followed by key differentiators. No redundant 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?

While the tool is simple and has an output schema, the description covers main behaviors (auto-detect, chunking). Missing are potential constraints (e.g., file size limits, permission requirements) but these are not critical for basic understanding.

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 all parameters described. The description adds chunking context relevant to the file path parameter but does not add per-parameter semantics beyond what the schema provides.

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 'Analyzes a whole code file from disk', specifying a verb and resource. It distinguishes from sibling 'analyze_code' by emphasizing file-based analysis and adds unique features like auto-language detection and chunking.

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 vs alternatives like 'analyze_code', 'explain_code', or 'compare_code'. The description implies file-based usage but does not exclude other cases or mention when not to use.

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

cache_infoA

Shows cache statistics or clears the cache Args: clear: True - clears the cache, False - shows statistics.

Returns: JSON with cache stats or clear result.

ParametersJSON Schema

Name	Required	Description	Default
`clear`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses both behaviors (show stats or clear cache) and the return format. Without annotations, it effectively communicates the tool's two modes and the parameter's role.

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?

Extremely concise: two sentences clearly stating purpose, parameter explanation, and return value. No wasted words.

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 covers the tool's main actions and return, but could benefit from mentioning any side effects of clearing the cache or requirements like authentication. However, given the output schema exists, it is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the sole parameter 'clear' with explicit meanings for true and false, adding complete semantic value beyond the schema's minimal type definition (0% 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 shows cache statistics or clears the cache, with specific verb and resource. It is distinct from sibling tools which focus on code analysis and report generation.

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?

No explicit guidance on when to use this tool versus alternatives. While siblings are unrelated, the description does not provide any context for when to choose one behavior over the other or any prerequisites.

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

compare_codeA

Compares two versions of code and evaluates whether the change is an improvement.

Performs a structured diff analysis: identifies what improved, what regressed, and what changed neutrally. Returns a merge recommendation based on the findings. Useful for code review, refactoring validation, and AI-generated code verification.

ParametersJSON Schema

Name	Required	Description	Default
`code_before`	Yes	The original version of the code (before changes). Include complete function or class -- not just the diff.
`code_after`	Yes	The new version of the code (after changes). Must be the same scope as code_before for accurate comparison.
`language`	No	Programming language of both versions. Examples: "python", "javascript", "go", "typescript". Defaults to "python".	python
`context`	No	Optional description of the intent behind the change. Helps distinguish intentional trade-offs from bugs. Example: "Optimized for memory usage at the cost of readability"

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It discloses the tool performs 'structured diff analysis' and returns a 'merge recommendation' with categories of improvements, regressions, and neutrals. It does not mention destructive actions or side effects, which aligns with a read-only analysis tool. A minor omission: no mention of output schema details, but the presence of an output schema is noted.

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 paragraphs with clear, front-loaded purpose. Every sentence adds value: first sentence states purpose, second paragraph outlines analysis outputs. No fluff or redundancy.

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

Completeness5/5

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

Given the presence of an output schema (not shown), and the schema's 100% coverage, the description sufficiently explains what the tool does, its outputs (improved, regressed, neutral, recommendation), and appropriate use cases. It is complete for a comparison tool.

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 baseline is 3. The description adds value by explaining that the 'context' parameter 'helps distinguish intentional trade-offs from bugs' and that the language parameter defaults to Python. This enriches the schema 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 it 'Compares two versions of code' and 'evaluates whether the change is an improvement'. The verb 'compares' and resource 'code versions' are specific. It distinguishes from siblings like analyze_code and explain_code by focusing on comparison.

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 explicitly lists use cases: 'code review, refactoring validation, and AI-generated code verification'. This provides clear context for when to use. It does not explicitly state when not to use or alternative tools, but the listed use cases are sufficient guidance.

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

explain_codeA

Explains what code does - step by step and clearly. Args: code: Code to explain. language: Programming language. audience: Target audience level - junior, middle, or senior. Returns: JSON with step-by-step explanation, key concepts, and gotchas.

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`language`	No	python
`audience`	No	junior

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states it explains code and returns JSON, but does not disclose behavioral traits like read-only, performance, or limitations. For a code explanation tool, this is insufficient.

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?

Description is short and front-loaded with purpose. The parameter section is structured but could be more concise if schema had descriptions. However, given no schema descriptions, it is appropriately sized.

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?

Tool has 3 parameters and output schema exists. Description explains return format (step-by-step explanation, key concepts, gotchas) but does not detail output schema fields. It lacks coverage of edge cases or limitations.

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 description coverage is 0%, so description adds significant value. It clearly describes each parameter: code, language (with default python), and audience (with levels junior/middle/senior). It also mentions defaults, which are not in schema 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 it 'explains what code does - step by step and clearly.' The verb 'explain' matches the tool name, and the resource is code. It distinguishes from siblings like 'analyze_code' by emphasizing step-by-step and clear explanation.

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?

No explicit guidance on when to use this vs alternatives. The description implies a teaching context, but does not provide exclusions or when-not-to-use. Sibling tools like 'analyze_code' or 'compare_code' might overlap, but no differentiation is given.

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

generate_reportA

Generates a beautiful HTML report from analyze_code or analyze_file results. Args: analysis_json: JSON string from analyze_code or analyze_file. output_path: Path to save the HTML file (optional). source_name: File/fragment name for the report title. Returns: JSON with fields: html, saved_to, length.

ParametersJSON Schema

Name	Required	Description	Default
`analysis_json`	Yes
`output_path`	No
`source_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses output format (JSON with fields html, saved_to, length) and optional parameters. Lacks details on side effects (e.g., file overwriting) or performance considerations, but adequately outlines basic behavior.

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?

Description is concise with clear structure: purpose sentence, then list of args and returns. No wasted words, all information 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?

Given the presence of an output schema, the description covers input source, optional parameters, and return format. Minor gaps in error handling or limitations, but sufficient for a tool that wraps other tools.

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?

With 0% schema description coverage, the description compensates well: explains analysis_json as JSON from specific sources, output_path as save path, and source_name as report title. Adds meaning beyond bare schema, though could include data type or format constraints.

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 generates an HTML report from analyze_code or analyze_file results, distinguishing it from sibling tools that perform analysis. Verb 'Generates' and specific resource 'HTML report' are explicit.

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?

Explicitly specifies that input should come from analyze_code or analyze_file, providing clear context. However, no exclusion criteria or alternatives are discussed, though implied by sibling tool list.

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

generate_testsA

Generates tests for the provided code. Args: code: Code to generate tests for. language: Programming language. framework: Test framework (optional - pytest, jest, unittest, etc.). Returns: JSON with test cases, runnable test code, and coverage estimate.

ParametersJSON Schema

Name	Required	Default
`code`	Yes
`language`	No	python
`framework`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

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 the return structure (JSON with test cases, runnable code, coverage estimate) but does not mention side effects, authorization needs, or rate limits. It is adequate but not rich.

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 front-loaded with purpose and efficiently lists parameters in an Args block. It is concise though slightly verbose with line breaks, but overall well-structured and easy to parse.

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 3 parameters and no annotations, the description covers purpose and parameters but lacks constraints on 'language' and 'framework' (e.g., allowed values). It mentions return structure but not pagination or error handling. Adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates fully by explaining each parameter (code, language, framework) with clear semantics. It adds value beyond the raw schema field names and defaults.

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 'Generates tests for the provided code', specifying the verb 'generates' and the resource 'tests for code'. It effectively distinguishes from sibling tools (e.g., analyze_code, explain_code) which focus on analysis rather than generation.

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 exclusions. It lacks explicit context for appropriate usage beyond the basic purpose.

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. Dates show when Glama detected each change.

6 tool updatesMay 13, 2026

Changedanalyze_code1 field changed

changedInput schema / properties / context / description

Before

"Optional description — what the code does or where it came from."

After

"Optional description - what the code does or where it came from."

Changedcache_info1 field changed
- removedInput schema / properties / clear / description
```
"True — clears the cache, False — shows statistics."
```

Changedcompare_code4 fields changed

changedInput schema / properties / code_after / description

Before

"New version of the code."

After

"The new version of the code (after changes).\n         Must be the same scope as code_before for accurate comparison."

changedInput schema / properties / code_before / description

Before

"Old version of the code."

After

"The original version of the code (before changes).\n         Include complete function or class -- not just the diff."

changedInput schema / properties / context / description

Before

"Description of what changed and why (optional)."

After

"Optional description of the intent behind the change.\n         Helps distinguish intentional trade-offs from bugs.\n         Example: \"Optimized for memory usage at the cost of readability\""

changedInput schema / properties / language / description

Before

"Programming language."

After

"Programming language of both versions.\n         Examples: \"python\", \"javascript\", \"go\", \"typescript\".\n         Defaults to \"python\"."

Changedexplain_code3 fields changed
- removedInput schema / properties / audience / description
```
"Target audience level — junior, middle, or senior."
```
- removedInput schema / properties / code / description
```
"Code to explain."
```
- removedInput schema / properties / language / description
```
"Programming language."
```
Changedgenerate_report3 fields changed
- removedInput schema / properties / analysis_json / description
```
"JSON string from analyze_code or analyze_file."
```
- removedInput schema / properties / output_path / description
```
"Path to save the HTML file (optional)."
```
- removedInput schema / properties / source_name / description
```
"File/fragment name for the report title."
```
Changedgenerate_tests3 fields changed
- removedInput schema / properties / code / description
```
"Code to generate tests for."
```
- removedInput schema / properties / framework / description
```
"Test framework (optional — pytest, jest, unittest, etc.)."
```
- removedInput schema / properties / language / description
```
"Programming language."
```

7 tool updatesv1.0.0May 5, 2026
- First observedanalyze_code
- First observedanalyze_file
- First observedcache_info
- First observedcompare_code
- First observedexplain_code
- First observedgenerate_report
- First observedgenerate_tests

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: code fragment analysis, whole file analysis, cache management, code comparison, code explanation, report generation, and test generation. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., analyze_code, generate_tests). No inconsistencies in style.

Tool Count5/5

7 tools is a well-scoped set for code analysis and sanitization tasks, covering the core operations without being overwhelming or too sparse.

Completeness4/5

The tool surface covers analysis, comparison, explanation, test generation, and reporting. A minor gap is the lack of code transformation or refactoring tools, but the set is reasonable for the stated domain.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

XRay-Vision
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2
Moltline Code Review A
com.moltlinestudio
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Code Analysis Developer Tools Testing & QA Tools
71
Python Code Reviewer B
org.duckdns.43-134-36-21
Security + bug + perf + refactor audit for Python. Returns 0-10 score + MD report.
Code Analysis Testing & QA Tools
21
HefestoAI A
io.github.artvepa80
Pre-commit code quality guardian. Detects semantic drift in AI-generated code.
Code Analysis Testing & QA Tools Developer Tools
421

Related MCP Servers

MCP-Python
Databases Developer Tools Search
rhabraken
F
license
Not graded
quality
D
maintenance
A server that enables interaction with PostgreSQL, MySQL, MariaDB, or SQLite databases through Claude Desktop using natural language queries.
Updated 2 years ago (2025-02-12 06:09 UTC)
1
-
Claude Code Review MCP
Code Analysis Developer Tools Code Execution
praneybehl
A
license
A
quality
F
maintenance
An MCP server that provides code review functionality using OpenAI, Google, and Anthropic models, serving as a "second opinion" tool that works with any MCP client.
Updated a year ago (2025-05-16 05:22 UTC)
1
42
33
MIT
MCP Security Scanner
Security Code Analysis Testing & QA Tools
JMitac
A
license
A
quality
D
maintenance
Enables comprehensive security scanning of code projects, detecting vulnerabilities in dependencies, code patterns (XSS, eval, etc.), and exposed secrets, with detailed reports in Spanish prioritized by severity.
Updated 9 months ago (2025-12-09 22:57 UTC)
4
150
MIT
open-code-review
Code Analysis Testing & QA Tools Developer Tools
raye-deng
F
license
A
quality
C
maintenance
AI-powered code review tool that detects AI-generated code defects invisible to traditional linters — hallucinated packages, deprecated APIs, cross-file contradictions, hidden security anti-patterns, and over-engineering. Works as a standalone CLI, GitHub Action, or MCP server. Supports TypeScript, Python, Java, Go, and Kotlin. Free for individuals, no API key required.
Updated 5 months ago (2026-04-16 06:01 UTC)
4
37
-

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/notasandy/mcp-code-sanitizer'

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

mcp-code-sanitizer

Features

Example output

Installation

Claude Code CLI

Claude Desktop

Cursor

VS Code

Manual install (alternative)

GitHub Action — automatic PR review

Usage in chat

Architecture

Configuration

Available Groq models

Contributing

License

Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API