de en es ja ko ru zh

codesafer

Name: codesafer
Author: goldmembrane

by goldmembrane

Overview Schema Related Servers Score Discussions

Local

CodeSafer (cleaner-code)

AI code security scanner as a Model Context Protocol (MCP) server. Detects hidden threats in AI-generated code that traditional linters miss.

npm license: ISC Node

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

Why CodeSafer?

AI coding assistants generate code fast — but who's checking it for hidden threats?

Recent supply-chain attacks show that malicious code can hide in ways human reviewers and traditional linters routinely miss:

Invisible Unicode characters injected into identifiers (30+ variants)
BiDi / Trojan Source attacks that reorder how code is displayed vs. executed (CVE-2021-42574)
Homoglyphs — Cyrillic characters masquerading as Latin (CVE-2021-42694)
Glassworm-style Unicode steganography hiding payloads in whitespace
Rules file backdoors planted in .cursorrules, CLAUDE.md, and other AI config files
Typosquatted dependencies in package.json
Obfuscation patterns — eval + base64, reverse shells, packed payloads

CodeSafer scans for all of these before the code runs on your machine.

Related MCP server: guardvibe

How it works

CodeSafer runs as a local MCP server. Your AI client (Claude Code, Cursor, etc.) calls its tools when reviewing or generating code, and findings are returned inline.

Hybrid detection:

8 static analysis scanners — deterministic rules for known attack categories (fast, zero false-negatives on the patterns they cover).
CodeBERT deep analysis — transformer model classifies code chunks as malicious/benign with confidence scores. Catches obfuscated or novel patterns that static rules miss.

Nothing leaves your machine. The AI analysis runs locally against a tokenizer server.

Features

Capability	Details
Invisible character detection	30+ Unicode variants including Zero-Width Space, Mongolian Vowel Separator
BiDi / Trojan Source	Full CVE-2021-42574 coverage
Homoglyph detection	Cyrillic/Greek/Latin confusables (CVE-2021-42694)
Unicode steganography	Glassworm-style whitespace payloads
Rules file backdoors	Scans `.cursorrules`, `CLAUDE.md`, `.claude/`, Cursor rules
Dependency scanning	Typosquatting + suspicious install scripts in `package.json`
Obfuscation detection	`eval` + base64, reverse shells, packed payloads
AI deep analysis	CodeBERT transformer classifier with confidence scores
MCP native	6 MCP tools, stdio transport
Local-first	No code uploaded — runs entirely on your machine

MCP Tools

CodeSafer exposes six tools to your MCP client:

Tool	Purpose
`scan_file`	Scan a single file for hidden malicious code patterns
`scan_directory`	Recursively scan a directory across all source files
`scan_rules_file`	Scan an AI configuration/rules file for prompt injection and Rules File Backdoor attacks
`check_dependencies`	Check `package.json` for typosquatting, suspicious install scripts, and dependency risks
`ai_analyze`	Deep AI analysis using the trained CodeBERT model (classifies chunks as malicious/benign with confidence)
`explain_finding`	Get detailed explanation of a specific threat category, with attack scenarios and remediation

Installation

Prerequisites

Node.js 18 or later
An MCP-compatible client (Claude Code, Cursor, VS Code + Copilot, Cline)

From source

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

Configure your MCP client

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

Restart your client, and CodeSafer tools will appear in the tool picker.

Usage

Once configured, ask your AI client things like:

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

The client will call the appropriate MCP tool and return findings with severity, line numbers, and remediation guidance.

Free tier & Plans

CodeSafer is free to use. Static analysis (scan_file, scan_directory, scan_rules_file, check_dependencies, explain_finding) has no limits.

AI deep analysis (ai_analyze) includes 10 free runs per session. Paid plans for higher AI quotas are available at codesafer.org.

Detection categories

CodeSafer detects threats across 9 categories:

Invisible Unicode characters — 30+ variants including Zero-Width Space, Zero-Width Joiner
BiDi / Trojan Source attacks — CVE-2021-42574
Homoglyphs — Cyrillic/Greek characters masquerading as Latin (CVE-2021-42694)
Unicode steganography — Glassworm patterns in whitespace
Rules file backdoors — malicious instructions in .cursorrules, CLAUDE.md, etc.
Dependency risks — typosquatting and suspicious install scripts
Obfuscation patterns — eval + base64, packed payloads, reverse shells
Static analysis findings — 8 deterministic scanners
AI deep analysis — CodeBERT transformer for novel and obfuscated threats

Project structure

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

License

ISC — see the LICENSE file for 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. 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

CodeSafer (cleaner-code)

Why CodeSafer?

How it works

Features

MCP Tools

Installation

Prerequisites

From source

Configure your MCP client

Usage

Free tier & Plans

Detection categories

Project structure

License

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API