de en es ja ko ru zh

codesafer

Name: codesafer
Author: goldmembrane

by goldmembrane

Overview Schema Source Related Servers Discussions Admin

Local

CodeSafer (cleaner-code)

KI-Code-Sicherheitsscanner als Model Context Protocol (MCP) Server. Erkennt versteckte Bedrohungen in KI-generiertem Code, die herkömmliche Linter übersehen.

npm license: ISC Node

Website: codesafer.org · MCP-Clients: Claude Code, Cursor, VS Code + Copilot, Cline

Warum CodeSafer?

KI-Coding-Assistenten generieren Code schnell – aber wer überprüft ihn auf versteckte Bedrohungen?

Aktuelle Angriffe auf die Lieferkette zeigen, dass bösartiger Code sich auf Arten verstecken kann, die menschliche Prüfer und herkömmliche Linter routinemäßig übersehen:

Unsichtbare Unicode-Zeichen, die in Bezeichner eingefügt werden (über 30 Varianten)
BiDi / Trojan Source-Angriffe, die die Anzeige von Code gegenüber seiner Ausführung verfälschen (CVE-2021-42574)
Homoglyphen – kyrillische Zeichen, die sich als lateinische tarnen (CVE-2021-42694)
Unicode-Steganographie im Glassworm-Stil, die Payloads in Leerzeichen versteckt
Backdoors in Regeldateien, die in .cursorrules, CLAUDE.md und anderen KI-Konfigurationsdateien platziert werden
Typosquatting-Abhängigkeiten in package.json
Obfuskationsmuster – eval + base64, Reverse Shells, gepackte Payloads

CodeSafer scannt auf all dies, bevor der Code auf Ihrem Rechner ausgeführt wird.

Related MCP server: guardvibe

Funktionsweise

CodeSafer läuft als lokaler MCP-Server. Ihr KI-Client (Claude Code, Cursor, etc.) ruft dessen Tools beim Überprüfen oder Generieren von Code auf, und die Ergebnisse werden inline zurückgegeben.

Hybride Erkennung:

8 statische Analysescan-Module – deterministische Regeln für bekannte Angriffskategorien (schnell, null falsch-negative Ergebnisse bei den abgedeckten Mustern).
CodeBERT-Deep-Analyse – ein Transformer-Modell klassifiziert Code-Abschnitte mit Konfidenzwerten als bösartig/gutartig. Erkennt obfuskierte oder neuartige Muster, die statische Regeln übersehen.

Nichts verlässt Ihren Rechner. Die KI-Analyse läuft lokal gegen einen Tokenizer-Server.

Funktionen

Fähigkeit	Details
Erkennung unsichtbarer Zeichen	Über 30 Unicode-Varianten, einschließlich Zero-Width Space, Mongolian Vowel Separator
BiDi / Trojan Source	Vollständige Abdeckung von CVE-2021-42574
Homoglyphen-Erkennung	Kyrillische/Griechische/Lateinische Verwechslungszeichen (CVE-2021-42694)
Unicode-Steganographie	Leerzeichen-Payloads im Glassworm-Stil
Backdoors in Regeldateien	Scannt `.cursorrules`, `CLAUDE.md`, `.claude/`, Cursor-Regeln
Abhängigkeitsscan	Typosquatting + verdächtige Installationsskripte in `package.json`
Obfuskationserkennung	`eval` + base64, Reverse Shells, gepackte Payloads
KI-Deep-Analyse	CodeBERT-Transformer-Klassifikator mit Konfidenzwerten
MCP-nativ	6 MCP-Tools, stdio-Transport
Local-first	Kein Code-Upload – läuft vollständig auf Ihrem Rechner

MCP-Tools

CodeSafer stellt Ihrem MCP-Client sechs Tools zur Verfügung:

Tool	Zweck
`scan_file`	Scannt eine einzelne Datei auf versteckte bösartige Codemuster
`scan_directory`	Scannt ein Verzeichnis rekursiv über alle Quelldateien hinweg
`scan_rules_file`	Scannt eine KI-Konfigurations-/Regeldatei auf Prompt-Injection und Backdoor-Angriffe in Regeldateien
`check_dependencies`	Überprüft `package.json` auf Typosquatting, verdächtige Installationsskripte und Abhängigkeitsrisiken
`ai_analyze`	Tiefe KI-Analyse unter Verwendung des trainierten CodeBERT-Modells (klassifiziert Abschnitte als bösartig/gutartig mit Konfidenz)
`explain_finding`	Detaillierte Erklärung einer spezifischen Bedrohungskategorie mit Angriffsszenarien und Behebung

Installation

Voraussetzungen

Node.js 18 oder neuer
Ein MCP-kompatibler Client (Claude Code, Cursor, VS Code + Copilot, Cline)

Aus dem Quellcode

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

Konfigurieren Sie Ihren MCP-Client

Claude Code (~/.claude.json oder Projekt .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"]
    }
  }
}

Starten Sie Ihren Client neu, und die CodeSafer-Tools erscheinen in der Tool-Auswahl.

Verwendung

Sobald die Konfiguration abgeschlossen ist, können Sie Ihren KI-Client Dinge fragen wie:

"Scan this file for hidden security issues."
"Check the dependencies in package.json for typosquatting."
"Scan .cursorrules for a rules-file backdoor."
"Run a deep AI analysis of src/auth.ts."
"Explain what a Trojan Source attack is and how to fix the finding above."

Der Client ruft das entsprechende MCP-Tool auf und gibt die Ergebnisse mit Schweregrad, Zeilennummern und Hinweisen zur Behebung zurück.

Kostenlose Stufe & Pläne

CodeSafer ist kostenlos nutzbar. Die statische Analyse (scan_file, scan_directory, scan_rules_file, check_dependencies, explain_finding) ist unbegrenzt.

Die KI-Deep-Analyse (ai_analyze) beinhaltet 10 kostenlose Durchläufe pro Sitzung. Kostenpflichtige Pläne für höhere KI-Kontingente sind unter codesafer.org verfügbar.

Erkennungskategorien

CodeSafer erkennt Bedrohungen in 9 Kategorien:

Unsichtbare Unicode-Zeichen – über 30 Varianten, einschließlich Zero-Width Space, Zero-Width Joiner
BiDi / Trojan Source-Angriffe – CVE-2021-42574
Homoglyphen – Kyrillische/Griechische Zeichen, die sich als lateinische tarnen (CVE-2021-42694)
Unicode-Steganographie – Glassworm-Muster in Leerzeichen
Backdoors in Regeldateien – bösartige Anweisungen in .cursorrules, CLAUDE.md, etc.
Abhängigkeitsrisiken – Typosquatting und verdächtige Installationsskripte
Obfuskationsmuster – eval + base64, gepackte Payloads, Reverse Shells
Statische Analyseergebnisse – 8 deterministische Scanner
KI-Deep-Analyse – CodeBERT-Transformer für neuartige und obfuskierte Bedrohungen

Projektstruktur

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

Lizenz

ISC – siehe die LICENSE-Datei für Details.

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-07 13:05 across 6 tools

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

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 a month 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 a month ago (2026-08-14 11:52 UTC)
39
331 npm
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 2 days ago (2026-09-20 10:30 UTC)
14
9 npm
15
Apache 2.0
mcp-security-audit
Penetration Testing CI/CD & DevOps
eltociear
A
license
Not graded
quality
B
maintenance
Scans MCP servers, AI agent skills, and plugins for 68+ malicious patterns including credential exfiltration, prompt injection, and code execution.
Updated a month ago (2026-08-19 05:09 UTC)
49 npm
6
MIT

CodeSafer (cleaner-code)

Warum CodeSafer?

Funktionsweise

Funktionen

MCP-Tools

Installation

Voraussetzungen

Aus dem Quellcode

Konfigurieren Sie Ihren MCP-Client

Verwendung

Kostenlose Stufe & Pläne

Erkennungskategorien

Projektstruktur

Lizenz

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers