de en es ja ko ru zh

MCP Code Sanitizer

Name: MCP Code Sanitizer
Author: notasandy

by notasandy

Overview Schema Related Servers Score Discussions

Python

🔍 mcp-code-sanitizer

Строгий AI-ревьюер кода, который проверяет ваш код с помощью Groq LLM прямо из Claude Desktop, Cursor или любого другого MCP-совместимого агента.

Python FastMCP Groq License

Claude Desktop  ──MCP──►  code-sanitizer  ──REST──►  Groq API
                            (server.py)               (llama-3.3-70b)

✨ Возможности

Инструмент	Описание
`analyze_code`	Строгий ревью кода — ошибки, уязвимости, оценка 0–100
`compare_code`	Сравнивает две версии, находит регрессии, рекомендует слияние/запрос изменений
`explain_code`	Пошаговое объяснение для уровня junior/middle/senior
`generate_tests`	Генерирует тесты pytest/jest/go с учетом основных сценариев, граничных случаев и проверок безопасности
`analyze_file`	Анализирует весь файл с диска с параллельным разбиением на части
`generate_report`	Создает красивый HTML-отчет на основе любого результата анализа
`cache_info`	Статистика кэша и его очистка

Пример ответа

{
  "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

🚀 Быстрый старт

1. Клонируйте репозиторий

git clone https://github.com/YOUR_USERNAME/mcp-code-sanitizer
cd mcp-code-sanitizer

2. Создайте виртуальное окружение и установите зависимости

python -m venv venv

# macOS / Linux
source venv/bin/activate

# Windows
venv\Scripts\activate

pip install -r requirements.txt

3. Добавьте ваш API-ключ Groq

Получите бесплатный ключ на console.groq.com/keys

cp .env.example .env
# Open .env and set GROQ_API_KEY=gsk_...

4. Протестируйте сервер

python server.py

Тишина означает, что все работает — сервер ожидает MCP-запросы через stdio.

🔌 Подключение к Claude Desktop

Найдите файл конфигурации и добавьте секцию mcpServers:

ОС	Путь к конфигурации
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": "/full/path/to/venv/bin/python",
      "args": ["/full/path/to/server.py"],
      "env": {
        "GROQ_API_KEY": "gsk_your_key_here"
      }
    }
  }
}

Перезапустите Claude Desktop — вы увидите иконку 🔧 в чате.

🔌 Подключение к Cursor

Создайте .cursor/mcp.json в корне вашего проекта:

{
  "mcpServers": {
    "code-sanitizer": {
      "command": "/full/path/to/venv/bin/python",
      "args": ["/full/path/to/server.py"],
      "env": {"GROQ_API_KEY": "gsk_your_key_here"}
    }
  }
}

🧪 Тестирование через MCP Inspector

source venv/bin/activate  # or venv\Scripts\activate on Windows
fastmcp dev inspector server.py

Откроется браузерный интерфейс с полным набором инструментов для тестирования.

💬 Использование в чате

После подключения к Claude Desktop просто напишите:

Review this code for vulnerabilities:

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

Или явно вызовите инструмент:

Use analyze_file on /path/to/my_script.py
Generate tests for this function: ...
Compare these two versions and tell me if it got better: ...

🏗️ Архитектура

mcp-code-sanitizer/
├── server.py          # FastMCP entry point (39 lines)
├── config.py          # Constants — keys, limits, mappings
├── groq_client.py     # Groq API client with auto-retry on rate limits
├── cache.py           # In-memory 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)

⚙️ Конфигурация

Все настройки задаются через переменные окружения или .env:

Переменная	По умолчанию	Описание
`GROQ_API_KEY`	—	Обязательно. Получите на console.groq.com
`GROQ_MODEL`	`llama-3.3-70b-versatile`	Модель Groq
`CACHE_TTL`	`3600`	Время жизни кэша в секундах
`CACHE_MAX`	`200`	Максимальное количество записей в кэше

Доступные модели Groq

Модель	Скорость	Качество
`llama-3.3-70b-versatile`	⚡⚡	⭐⭐⭐⭐⭐ (по умолчанию)
`llama-3.1-8b-instant`	⚡⚡⚡	⭐⭐⭐
`mixtral-8x7b-32768`	⚡⚡	⭐⭐⭐⭐

📦 Требования

fastmcp>=2.3.0
httpx>=0.27.0
python-dotenv>=1.0.0

🤝 Участие в разработке

PR и Issues приветствуются! Особенно интересны:

Поддержка других LLM-провайдеров (OpenAI, Anthropic)
Новые инструменты (аудит безопасности, проверка зависимостей, анализ сложности)
Улучшения промптов

📄 Лицензия

MIT — делайте что хотите. Будем признательны за звезду на GitHub ⭐

🔗 Ссылки

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

Previous value: -"Optional description — what the code does or where it came from."New value: +"Optional description - what the code does or where it came from."

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

Changedcompare_code4 fields changed

changedInput schema / properties / code_after / description

Previous value: -"New version of the code."New value: +"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

Previous value: -"Old version of the code."New value: +"The original version of the code (before changes).\n         Include complete function or class -- not just the diff."

changedInput schema / properties / context / description

Previous value: -"Description of what changed and why (optional)."New value: +"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

Previous value: -"Programming language."New value: +"Programming language of both versions.\n         Examples: \"python\", \"javascript\", \"go\", \"typescript\".\n         Defaults to \"python\"."

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