de en es ja ko ru zh

codesafer

Name: codesafer
Author: goldmembrane

by goldmembrane

Overview Schema Related Servers Score Discussions

Local

CodeSafer (cleaner-code)

Сканер безопасности ИИ-кода в качестве сервера протокола контекста модели (MCP). Обнаруживает скрытые угрозы в коде, созданном ИИ, которые пропускают традиционные линтеры.

npm license: ISC Node

Веб-сайт: codesafer.org · MCP-клиенты: Claude Code, Cursor, VS Code + Copilot, Cline

Почему CodeSafer?

ИИ-ассистенты пишут код быстро, но кто проверяет его на наличие скрытых угроз?

Недавние атаки на цепочки поставок показывают, что вредоносный код может скрываться способами, которые люди-рецензенты и традиционные линтеры регулярно пропускают:

Невидимые символы Unicode, внедренные в идентификаторы (более 30 вариантов)
Атаки BiDi / Trojan Source, которые меняют порядок отображения кода по сравнению с его выполнением (CVE-2021-42574)
Омоглифы — кириллические символы, маскирующиеся под латиницу (CVE-2021-42694)
Стеганография Unicode в стиле Glassworm, скрывающая полезную нагрузку в пробелах
Бэкдоры в файлах правил, внедренные в .cursorrules, CLAUDE.md и другие конфигурационные файлы ИИ
Тайпсквоттинг зависимостей в package.json
Шаблоны обфускации — eval + base64, обратные оболочки (reverse shells), упакованные полезные нагрузки

CodeSafer сканирует всё это до того, как код будет запущен на вашей машине.

Related MCP server: guardvibe

Как это работает

CodeSafer работает как локальный MCP-сервер. Ваш ИИ-клиент (Claude Code, Cursor и т. д.) вызывает его инструменты при просмотре или генерации кода, а результаты возвращаются в виде встроенных сообщений.

Гибридное обнаружение:

8 сканеров статического анализа — детерминированные правила для известных категорий атак (быстро, отсутствие ложноотрицательных результатов для покрываемых ими шаблонов).
Глубокий анализ CodeBERT — модель-трансформер классифицирует фрагменты кода как вредоносные/безопасные с оценкой достоверности. Обнаруживает обфусцированные или новые шаблоны, которые пропускают статические правила.

Ничего не покидает вашу машину. ИИ-анализ выполняется локально с использованием токенизатора.

Возможности

Возможность	Подробности
Обнаружение невидимых символов	30+ вариантов Unicode, включая неразрывный пробел, монгольский разделитель гласных
BiDi / Trojan Source	Полное покрытие CVE-2021-42574
Обнаружение омоглифов	Конфликтующие символы кириллицы/греческого/латиницы (CVE-2021-42694)
Стеганография Unicode	Полезная нагрузка в пробелах в стиле Glassworm
Бэкдоры в файлах правил	Сканирование `.cursorrules`, `CLAUDE.md`, `.claude/`, правил Cursor
Сканирование зависимостей	Тайпсквоттинг + подозрительные скрипты установки в `package.json`
Обнаружение обфускации	`eval` + base64, обратные оболочки, упакованные полезные нагрузки
Глубокий ИИ-анализ	Классификатор-трансформер CodeBERT с оценкой достоверности
MCP native	6 инструментов MCP, транспорт stdio
Локально-ориентированный	Код не загружается — работает полностью на вашей машине

Инструменты MCP

CodeSafer предоставляет шесть инструментов для вашего MCP-клиента:

Инструмент	Назначение
`scan_file`	Сканирование одного файла на наличие скрытых шаблонов вредоносного кода
`scan_directory`	Рекурсивное сканирование каталога по всем исходным файлам
`scan_rules_file`	Сканирование файла конфигурации/правил ИИ на наличие инъекций промптов и бэкдоров в файлах правил
`check_dependencies`	Проверка `package.json` на тайпсквоттинг, подозрительные скрипты установки и риски зависимостей
`ai_analyze`	Глубокий ИИ-анализ с использованием обученной модели CodeBERT (классифицирует фрагменты как вредоносные/безопасные с достоверностью)
`explain_finding`	Получение подробного объяснения конкретной категории угрозы со сценариями атак и методами устранения

Установка

Предварительные требования

Node.js 18 или новее
MCP-совместимый клиент (Claude Code, Cursor, VS Code + Copilot, Cline)

Из исходного кода

git clone https://github.com/goldmembrane/cleaner-code.git
cd cleaner-code
npm install
npm run build

Настройка вашего MCP-клиента

Claude Code (~/.claude.json или проектный .mcp.json):

{
  "mcpServers": {
    "codesafer": {
      "command": "node",
      "args": ["/absolute/path/to/cleaner-code/dist/index.js"]
    }
  }
}

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "codesafer": {
      "command": "node",
      "args": ["/absolute/path/to/cleaner-code/dist/index.js"]
    }
  }
}

Перезапустите клиент, и инструменты CodeSafer появятся в меню выбора инструментов.

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

После настройки задавайте своему ИИ-клиенту вопросы, например:

"Просканируй этот файл на наличие скрытых проблем безопасности."
"Проверь зависимости в package.json на наличие тайпсквоттинга."
"Просканируй .cursorrules на наличие бэкдора в файле правил."
"Запусти глубокий ИИ-анализ src/auth.ts."
"Объясни, что такое атака Trojan Source и как исправить найденную проблему."

Клиент вызовет соответствующий инструмент MCP и вернет результаты с указанием серьезности, номеров строк и рекомендаций по устранению.

Бесплатный тариф и планы

CodeSafer бесплатен в использовании. Статический анализ (scan_file, scan_directory, scan_rules_file, check_dependencies, explain_finding) не имеет ограничений.

Глубокий ИИ-анализ (ai_analyze) включает 10 бесплатных запусков за сессию. Платные планы для увеличения квот ИИ доступны на codesafer.org.

Категории обнаружения

CodeSafer обнаруживает угрозы в 9 категориях:

Невидимые символы Unicode — 30+ вариантов, включая неразрывный пробел, неразрывный соединитель
Атаки BiDi / Trojan Source — CVE-2021-42574
Омоглифы — кириллические/греческие символы, маскирующиеся под латиницу (CVE-2021-42694)
Стеганография Unicode — шаблоны Glassworm в пробелах
Бэкдоры в файлах правил — вредоносные инструкции в .cursorrules, CLAUDE.md и т. д.
Риски зависимостей — тайпсквоттинг и подозрительные скрипты установки
Шаблоны обфускации — eval + base64, упакованные полезные нагрузки, обратные оболочки
Результаты статического анализа — 8 детерминированных сканеров
Глубокий ИИ-анализ — трансформер CodeBERT для новых и обфусцированных угроз

Структура проекта

cleaner-code/
├── src/
│   ├── index.ts           # MCP server entry point
│   ├── api-server.ts      # Optional HTTP API server
│   ├── types.ts           # Scanner interfaces
│   ├── utils.ts           # File collection, summary formatting
│   └── scanner/
│       ├── invisible.ts       # Invisible Unicode scanner
│       ├── bidi.ts            # BiDi / Trojan Source scanner
│       ├── homoglyph.ts       # Homoglyph scanner
│       ├── encoding.ts        # Encoding / charset scanner
│       ├── obfuscation.ts     # Obfuscation pattern scanner
│       ├── steganography.ts   # Unicode steganography scanner
│       ├── rules-backdoor.ts  # Rules file backdoor scanner
│       ├── dependency.ts      # Dependency risk scanner
│       └── ai-analyzer.ts     # CodeBERT deep analyzer
├── ml/                    # ML model assets and tokenizer
├── functions/             # Cloud function deployments
├── deploy/                # Deployment manifests
└── web/                   # Landing page assets

Лицензия

ISC — подробности см. в файле LICENSE.

Ссылки

Веб-сайт: codesafer.org
Протокол контекста модели: modelcontextprotocol.io
Сообщить об ошибках: GitHub Issues

Available Tools

6 tools

ai_analyzeA

Deep AI analysis of code using the trained CodeBERT model. Classifies code chunks as malicious or benign with confidence scores. Detects obfuscated payloads, novel attack patterns, and threats that static rules may miss.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to the file to analyze with AI

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It mentions classification and detection capabilities but does not disclose behavioral traits like read-only nature, output format, or confidence score interpretation. Adequate but not fully transparent.

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 that are front-loaded with the core purpose, then expand on capabilities. 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?

For a simple tool with one parameter and no output schema, the description adequately covers purpose and capabilities. It could mention confidence score range or output format for clarity, but overall is sufficient.

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 a clear description for the single parameter. The description adds no extra semantic detail beyond the schema, so baseline 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 function: deep AI analysis using CodeBERT, classifying code as malicious/benign with confidence scores. It distinguishes itself from siblings like scan_file by emphasizing AI-based detection of obfuscated payloads and novel patterns.

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 use when static rules may miss threats, but lacks explicit guidance on when to use this tool over siblings like scan_file or scan_rules_file. No clear when-not or alternative recommendations.

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

check_dependenciesB

Check package.json for typosquatting, suspicious install scripts, and dependency risks

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to package.json file

TDQS

B3.2/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 lists checks performed but omits behavioral traits such as whether it modifies files, requires network access, or performance impact. Minimal behavioral context.

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?

One sentence, no unnecessary words, front-loaded with core 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?

No output schema and no mention of return format (e.g., report, status). For a security scan tool, more information about output and side effects is expected.

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 description for file_path. Description does not add meaning beyond schema, so 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?

Description clearly states it checks package.json for specific security risks: typosquatting, suspicious install scripts, and dependency risks. Verb+resource+scope is specific and 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 guidance on when to use this tool versus siblings like scan_file or scan_directory. No 'when not to use' or alternative suggestions provided.

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

explain_findingA

Get detailed explanation of a specific threat category including attack scenarios, real-world examples, and remediation steps

ParametersJSON Schema

Name	Required	Description	Default
`category`	Yes	The threat category to explain

TDQS

A3.9/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 full burden. It indicates a read-only operation ('Get detailed explanation') with no side effects. While it does not explicitly state that no changes occur, the purpose is clearly informational, which is sufficiently transparent for a lookup tool.

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 sentence of 20 words, directly conveying the tool's purpose without any unnecessary information. It is front-loaded with the key verb and resource.

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?

For a simple lookup tool with one enum parameter and no output schema or annotations, the description adequately covers the function. It lists the types of content in the explanation, making it complete for the given complexity.

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% as the sole parameter 'category' has an enum and description. The tool description does not add extra meaning to the parameter beyond what the schema already provides. The description adds context about the output but not about the parameter itself, so baseline 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 provides detailed explanations for threat categories including attack scenarios, real-world examples, and remediation steps. It uses a specific verb ('Get detailed explanation') and resource ('threat category'), and distinguishes itself from sibling tools that perform scanning or analysis.

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 does not mention when to use this tool versus alternatives. It implies usage when an explanation of a threat category is needed, but fails to provide explicit guidance or context for when not to use it. Given the simple nature, some guidance would improve agent selection.

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

scan_directoryB

Recursively scan a directory for hidden malicious code patterns across all source files

ParametersJSON Schema

Name	Required	Description	Default
`dir_path`	Yes	Absolute path to the directory to scan
`extensions`	No	File extensions to scan (e.g., [".js", ".ts"]). Defaults to common source file extensions.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It indicates recursive scanning but does not disclose performance implications, file modification behavior, or required permissions. More behavioral context is needed.

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 a single concise sentence with no unnecessary words. It is front-loaded with the core action. Could be slightly more structured but is efficient.

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 no output schema and security scanning complexity, the description lacks details on output format, result interpretation, and prerequisites. It is incomplete for an agent to fully understand usage without additional context.

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?

Input schema coverage is 100% with descriptions for both parameters. The description adds context like 'recursively' implying dir_path is a directory, but does not significantly enhance the schema's existing details. Baseline 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 explicitly states the tool recursively scans a directory for hidden malicious code patterns, which is a specific verb+resource combination. It clearly distinguishes from siblings like scan_file (single file) and scan_rules_file (rules file).

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 usage for scanning directories but does not explicitly state when to use this tool versus alternatives like scan_file or ai_analyze. No exclusions or prerequisites are provided.

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

scan_fileB

Scan a single file for hidden malicious code patterns (invisible chars, BiDi, homoglyphs, steganography, obfuscation, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Absolute path to the file to scan

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions what it scans for but omits whether the tool modifies the file, required permissions, rate limits, or return structure. This is insufficient for an agent to safely invoke the tool.

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?

Single, focused sentence with no unnecessary words. Efficiently conveys the core functionality.

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?

Lists relevant malicious patterns but lacks information about output format, success/failure indicators, or behavioral guarantees (e.g., read-only). Without output schema, this gap is notable.

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?

Input schema has 100% coverage for the single parameter 'file_path', which has a clear description. The tool's description adds no extra semantic value beyond what the schema already provides.

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?

Description clearly states the tool scans a single file for hidden malicious code patterns, listing specific pattern types. However, it does not explicitly distinguish from sibling tools like scan_directory or scan_rules_file, which could cause confusion.

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 (e.g., scan_directory for directories, ai_analyze for broader analysis). No mention of limitations or prerequisites.

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

scan_rules_fileA

Scan an AI configuration/rules file for prompt injection and Rules File Backdoor attacks

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to the AI rules file (e.g., .cursorrules, CLAUDE.md)

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses the input (file_path) and what it scans for, but does not mention return values, error conditions, permission requirements, or side effects. Lacks behavioral depth.

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?

A single sentence that is front-loaded with the action and target. No unnecessary words. Efficient and clear.

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 tool's simplicity (1 parameter, no output schema), the description is mostly adequate. However, it could improve by specifying what the output looks like (e.g., a boolean or list of findings) to be 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?

Schema coverage is 100%, so baseline is 3. The description's mention of 'AI configuration/rules file' adds minimal value beyond the schema's example file paths. No additional parameter semantics provided.

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 verb (scan), resource (AI configuration/rules file), and purpose (detect prompt injection and Rules File Backdoor attacks). It distinguishes itself from sibling tools like scan_file and scan_directory by specifying the exact file type and threats.

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 such as scan_file for generic file scanning or scan_directory for directories. No context on prerequisites or conditions for use.

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 updatesv1.0.0Apr 13, 2026
- First observedai_analyze
- First observedcheck_dependencies
- First observedexplain_finding
- First observedscan_directory
- First observedscan_file
- First observedscan_rules_file

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: scan_file vs scan_directory differ by scope, ai_analyze uses ML, check_dependencies focuses on dependencies, and scan_rules_file is for configuration files. No ambiguity.

Naming Consistency4/5

Tools mostly follow verb_noun snake_case pattern (e.g., scan_file, check_dependencies). The outlier is ai_analyze, which uses a prefix instead of a verb-noun structure, but it's still clear and consistent overall.

Tool Count5/5

With 6 tools covering scanning, AI analysis, dependency checks, and explanations, the count is well-scoped for a focused security analysis server. Not too many or too few.

Completeness4/5

The tools cover core scanning and analysis tasks well, including file/directory scanning, dependency risks, AI-based analysis, and explanations. A minor gap is the lack of a tool for aggregated reporting or finding management, but the surface is largely complete for detection and explanation.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
agent-sec A
ai.kernora
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Security Code Analysis
221
Raziel A
io.github.tide-foundation
MCP server teaching AI agents to implement TideCloak: auth, E2EE, IGA, security analysis
Security Autonomous Agents
202

Related MCP Servers

project-shield
Security Testing & QA Tools Code Analysis
Whitening-Sinabro
A
license
Not graded
quality
C
maintenance
Security scanner for MCP servers and AI-generated code. Detects leaked API keys, PII, prompt injection, and MCP misconfigs with A-F security grades.
Updated 25 days ago (2026-08-12 18:57 UTC)
MIT
guardvibe
Code Analysis Security
goklab
A
license
A
quality
A
maintenance
Security MCP server with 300+ rules for AI-generated code. Scans Next.js, Supabase, Clerk, Stripe, Prisma, Hono, GraphQL and 20+ modules. Zero config, runs locally.
Updated 23 days ago (2026-08-14 11:52 UTC)
39
393
5
Apache 2.0
depguard
Code Analysis Developer Tools Security
mopanc
A
license
A
quality
A
maintenance
MCP security server for AI coding agents. 12 tools: pre-install guardian, vulnerability audit, supply-chain attack detection via static code analysis, and CycloneDX 1.6 SBOM generation. Zero runtime dependencies.
Updated 3 days ago (2026-09-03 10:35 UTC)
14
43
15
Apache 2.0
mcp-security-audit
Penetration Testing CI/CD & DevOps
eltociear
A
license
Not graded
quality
A
maintenance
Scans MCP servers, AI agent skills, and plugins for 68+ malicious patterns including credential exfiltration, prompt injection, and code execution.
Updated 18 days ago (2026-08-19 05:09 UTC)
62
5
MIT

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/goldmembrane/cleaner-code'

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