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)

Escáner de seguridad de código por IA como servidor del Protocolo de Contexto de Modelo (MCP). Detecta amenazas ocultas en código generado por IA que los linters tradicionales pasan por alto.

npm license: ISC Node

Sitio web: codesafer.org · Clientes MCP: Claude Code, Cursor, VS Code + Copilot, Cline

¿Por qué CodeSafer?

Los asistentes de codificación por IA generan código rápidamente, pero ¿quién lo revisa en busca de amenazas ocultas?

Los ataques recientes a la cadena de suministro demuestran que el código malicioso puede esconderse de formas que los revisores humanos y los linters tradicionales pasan por alto habitualmente:

Caracteres Unicode invisibles inyectados en identificadores (más de 30 variantes)
Ataques BiDi / Trojan Source que reordenan cómo se muestra el código frente a cómo se ejecuta (CVE-2021-42574)
Homoglifos — caracteres cirílicos que se hacen pasar por latinos (CVE-2021-42694)
Esteganografía Unicode estilo Glassworm que oculta cargas útiles en espacios en blanco
Puertas traseras en archivos de reglas plantadas en .cursorrules, CLAUDE.md y otros archivos de configuración de IA
Dependencias con typosquatting en package.json
Patrones de ofuscación — eval + base64, reverse shells, cargas útiles empaquetadas

CodeSafer busca todo esto antes de que el código se ejecute en su máquina.

Related MCP server: guardvibe

Cómo funciona

CodeSafer se ejecuta como un servidor MCP local. Su cliente de IA (Claude Code, Cursor, etc.) llama a sus herramientas al revisar o generar código, y los hallazgos se devuelven en línea.

Detección híbrida:

8 escáneres de análisis estático — reglas deterministas para categorías de ataque conocidas (rápido, cero falsos negativos en los patrones que cubren).
Análisis profundo con CodeBERT — el modelo transformer clasifica fragmentos de código como maliciosos/benignos con puntuaciones de confianza. Detecta patrones ofuscados o novedosos que las reglas estáticas pasan por alto.

Nada sale de su máquina. El análisis de IA se ejecuta localmente contra un servidor tokenizador.

Características

Capacidad	Detalles
Detección de caracteres invisibles	Más de 30 variantes Unicode, incluyendo espacio de ancho cero, separador de vocales mongol
BiDi / Trojan Source	Cobertura completa de CVE-2021-42574
Detección de homoglifos	Confusibles cirílicos/griegos/latinos (CVE-2021-42694)
Esteganografía Unicode	Cargas útiles en espacios en blanco estilo Glassworm
Puertas traseras en archivos de reglas	Escanea `.cursorrules`, `CLAUDE.md`, `.claude/`, reglas de Cursor
Escaneo de dependencias	Typosquatting + scripts de instalación sospechosos en `package.json`
Detección de ofuscación	`eval` + base64, reverse shells, cargas útiles empaquetadas
Análisis profundo de IA	Clasificador transformer CodeBERT con puntuaciones de confianza
Nativo MCP	6 herramientas MCP, transporte stdio
Local-first	No se sube código — se ejecuta completamente en su máquina

Herramientas MCP

CodeSafer expone seis herramientas a su cliente MCP:

Herramienta	Propósito
`scan_file`	Escanea un solo archivo en busca de patrones de código malicioso ocultos
`scan_directory`	Escanea recursivamente un directorio en todos los archivos fuente
`scan_rules_file`	Escanea un archivo de configuración/reglas de IA en busca de inyección de prompts y ataques de puerta trasera en archivos de reglas
`check_dependencies`	Comprueba `package.json` en busca de typosquatting, scripts de instalación sospechosos y riesgos de dependencias
`ai_analyze`	Análisis profundo de IA utilizando el modelo entrenado CodeBERT (clasifica fragmentos como maliciosos/benignos con confianza)
`explain_finding`	Obtiene una explicación detallada de una categoría de amenaza específica, con escenarios de ataque y remediación

Instalación

Requisitos previos

Node.js 18 o posterior
Un cliente compatible con MCP (Claude Code, Cursor, VS Code + Copilot, Cline)

Desde el código fuente

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

Configure su cliente MCP

Claude Code (~/.claude.json o .mcp.json del proyecto):

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

Reinicie su cliente y las herramientas de CodeSafer aparecerán en el selector de herramientas.

Uso

Una vez configurado, pídale a su cliente de IA cosas como:

"Escanea este archivo en busca de problemas de seguridad ocultos."
"Comprueba las dependencias en package.json en busca de typosquatting."
"Escanea .cursorrules en busca de una puerta trasera en el archivo de reglas."
"Ejecuta un análisis profundo de IA de src/auth.ts."
"Explica qué es un ataque Trojan Source y cómo solucionar el hallazgo anterior."

El cliente llamará a la herramienta MCP adecuada y devolverá los hallazgos con la gravedad, los números de línea y la guía de remediación.

Nivel gratuito y planes

CodeSafer es de uso gratuito. El análisis estático (scan_file, scan_directory, scan_rules_file, check_dependencies, explain_finding) no tiene límites.

El análisis profundo de IA (ai_analyze) incluye 10 ejecuciones gratuitas por sesión. Hay planes de pago disponibles para cuotas de IA más altas en codesafer.org.

Categorías de detección

CodeSafer detecta amenazas en 9 categorías:

Caracteres Unicode invisibles — más de 30 variantes, incluyendo espacio de ancho cero, unión de ancho cero
Ataques BiDi / Trojan Source — CVE-2021-42574
Homoglifos — caracteres cirílicos/griegos que se hacen pasar por latinos (CVE-2021-42694)
Esteganografía Unicode — patrones Glassworm en espacios en blanco
Puertas traseras en archivos de reglas — instrucciones maliciosas en .cursorrules, CLAUDE.md, etc.
Riesgos de dependencias — typosquatting y scripts de instalación sospechosos
Patrones de ofuscación — eval + base64, cargas útiles empaquetadas, reverse shells
Hallazgos de análisis estático — 8 escáneres deterministas
Análisis profundo de IA — CodeBERT transformer para amenazas novedosas y ofuscadas

Estructura del proyecto

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

Licencia

ISC — consulte el archivo LICENSE para obtener más detalles.

Enlaces

Sitio web: codesafer.org
Protocolo de Contexto de Modelo: modelcontextprotocol.io
Informar de problemas: 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.

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