Which integrations are available for this server?

Identifies exposed Datadog API keys in project files to prevent accidental leakage. Scans for unprotected .env files and checks gitignore coverage to prevent accidental exposure of environment variables. Detects exposed GitHub tokens (e.g., ghp_, gho_, ghs_) in source files and environment files to prevent accidental leakage. Identifies exposed Google API keys and OAuth client secrets in project files to prevent accidental leakage. Detects exposed OpenAI API keys in source files and environment files to prevent accidental leakage. Identifies exposed SendGrid API keys (SG.xxx) in project files to prevent accidental leakage. Detects exposed Sentry DSNs in source files and environment files to prevent accidental leakage. Identifies exposed Slack tokens (xox*) in project files to prevent accidental leakage. Detects exposed Stripe secret/publishable keys and webhook secrets in source files and environment files to prevent accidental leakage. Identifies exposed Twilio auth tokens and account SIDs in project files to prevent accidental leakage.

How do I use env-secret-exposure-analyzer-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@env-secret-exposure-analyzer-mcp scan this project for secret exposure risks" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

env-secret-exposure-analyzer-mcp

by vola-trebla

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

🔐 env-secret-exposure-analyzer-mcp

npm License: MIT

Your AI agent is one debug session away from leaking your secrets.

MCP server that scans your project for secret exposure risks — hardcoded API keys, unprotected .env files, and console.log calls that print credentials at runtime. Before your agent accidentally reads them out loud.

🤔 The problem

You ask your AI agent to debug a config issue. It reads src/config.ts. Inside:

console.log('Config loaded:', JSON.stringify(config));
console.log(process.env.DATABASE_PASSWORD);

The agent now has your database password in its context. It might log it, include it in a summary, or pass it to another tool. And your .env isn't in .gitignore, so the next git push will do the rest.

None of this requires the agent to be malicious. It just needs to be helpful.

env-secret-exposure-analyzer-mcp catches this before it happens. 🔐

Related MCP server: GuardX

🛠️ Tools

`scan_for_secrets`

Scans source files, config files, and .env files for 20+ secret patterns. Returns file path, line number, severity, and a masked preview — never the full value.

Detects:

AWS access keys + secret keys
GitHub tokens (ghp_, gho_, ghs_)
Stripe secret/publishable keys + webhook secrets (whsec_)
Anthropic, OpenAI API keys
SendGrid (SG.xxx), Twilio auth token + account SID
Google API keys + OAuth client secrets (GOCSPX-)
Slack tokens (xox*)
Private keys (-----BEGIN ... PRIVATE KEY-----)
Database URLs with embedded credentials (postgres://user:pass@host)
JWT secrets, session secrets, encryption keys
Sentry DSN, Datadog API key
Generic hardcoded passwords, secrets, tokens

Secret Scan Results
  Project:       /project
  Files scanned: 24
  Findings:      5

  [CRITICAL] .env:3 — AWS Access Key
    Preview: AKIA****MPLE
  [CRITICAL] .env:7 — Database URL with password
    Preview: post****sswd
  [CRITICAL] src/auth.ts:12 — Hardcoded JWT secret
    Preview: my-s****ecret
  [HIGH] .env:14 — Hardcoded session secret
    Preview: sess****key!
  [MEDIUM] .env:28 — Sentry DSN
    Preview: http****7890

`check_gitignore_coverage`

Checks whether sensitive files (.env, .env.local, secrets.json, private keys, certificates) are covered by .gitignore. Flags files that could be accidentally committed.

Gitignore Coverage Check
  Project: /project

  ✗ .env → Add to .gitignore: .env
  ✗ .env.local → Add to .gitignore: .env.local
  ✓ secrets.json

`scan_for_log_leaks`

Scans source files for console.log / logger calls that print process.env variables or objects with secret-sounding names at runtime. Catches the most common "it's just a debug line" mistakes.

Log Leak Scan
  Project:       /project
  Files scanned: 18
  Findings:      3

  [CRITICAL] src/config.ts:8
    console.log("Config loaded:", JSON.stringify(config));
  [HIGH] src/server.ts:42
    console.log(process.env.AWS_SECRET_ACCESS_KEY);
  [HIGH] src/db.ts:15
    logger.info({ password: dbConfig.password });

🧪 What it looks like in practice

A realistic .env with 20 secrets — database URLs, AWS, Stripe, Twilio, SendGrid, Google OAuth, Sentry, JWT secrets, encryption keys. Before this MCP: an AI agent reads the file, has no idea what's sensitive, and proceeds to use those values in generated code or responses.

After one scan_for_secrets call: 16 findings, all categorized by severity, all previews masked. The agent knows exactly what's dangerous before it touches anything.

⚡ Setup

{
  "mcpServers": {
    "secret-scanner": {
      "command": "npx",
      "args": ["-y", "env-secret-exposure-analyzer-mcp"]
    }
  }
}

🚀 Usage

"Scan this project for any secrets or API keys that might be exposed. Check if .env files are in .gitignore, and look for any console.log calls that might be leaking credentials."

The agent runs all three tools in sequence and reports a full picture: what's hardcoded, what's not protected, what's being logged.

Works great alongside:

tsconfig-inheritance-flattener-mcp — for TypeScript config analysis
release-readiness-triage-mcp — for CI triage before release
ast-impact-mapper-mcp — for code→test correlation

📦 Links

npm: npmjs.com/package/env-secret-exposure-analyzer-mcp
GitHub: github.com/vola-trebla/env-secret-exposure-analyzer-mcp

License

MIT

Available Tools

5 tools

check_gitignore_coverageA

Check whether sensitive files (.env, .env.local, secrets.json, etc.) are properly covered by .gitignore rules. Flags files that contain secrets but could be accidentally committed.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	Absolute path to the project root to check

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full responsibility. It discloses the key behavior (flags files that could be accidentally committed) but omits details about read-only nature, return format, or potential false positives. This is adequate for a simple check tool but not thorough.

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?

Two focused sentences: the first defines the tool's purpose with examples, the second explains the flagging behavior. No redundant information or filler words.

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?

With no output schema, the description only vaguely says 'flags files' without specifying return format or prerequisites. This is minimally sufficient for a single-parameter tool, but additional details about output or limitations would improve completeness.

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?

The schema provides a complete description for the only parameter ('Absolute path to the project root'), so the description adds no additional parameter semantics. Baseline 3 applies due to high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks whether sensitive files are covered by .gitignore rules, naming specific examples (.env, secrets.json). It distinguishes itself from sibling scan tools by focusing on coverage rather than content scanning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: to verify sensitive files are protected from accidental commits. It doesn't explicitly name alternatives or exclusions, but the distinction from sibling scan tools is implied.

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

scan_ci_workflowsA

Scans GitHub Actions (.github/workflows/.yml), CircleCI (.circleci/config.yml), and GitLab CI (.gitlab-ci.yml) workflow files for dangerous secret interpolation patterns. Detects ${{ secrets. }} and ${{ github.token }} used directly in run: steps (log_leak risk — GitHub Actions logs the expanded plaintext) and ${{ github.event.pull_request.* }} / issue / commit content interpolated in shell commands (injection risk — attacker-controlled input). Returns file, job, step, pattern_found, risk, and recommendation.

ParametersJSON Schema

Name	Required	Description	Default
`repo_path`	Yes	Absolute path to the repository root to scan

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries full behavioral transparency. It explains the two risk categories (log leak and injection), how the risks arise, and what output fields to expect (file, job, step, pattern_found, risk, recommendation). This goes beyond a typical scan tool description.

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?

Two sentences deliver substantial detail: file paths, patterns, risk explanations, and return fields. Every clause provides useful context without redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is comprehensive for a scanning tool with no output schema, listing both detection patterns and return fields. It does not address edge cases like repositories without CI files or error handling, but given the sibling context and clarity, it is sufficiently 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?

The schema covers the single parameter repo_path with a clear description. The tool description itself does not add further parameter details, which is acceptable given 100% schema coverage, but it does not exceed the baseline.

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 uses a specific verb 'Scans' and names exact resources: GitHub Actions, CircleCI, and GitLab CI workflow files. It clearly differentiates from siblings by focusing on CI workflows and specific dangerous interpolation patterns, unlike general secret scanning or log leak tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on what it targets (CI workflow files) and what it detects, but it does not explicitly state when to use this tool over alternatives like scan_for_secrets or scan_for_log_leaks. The specificity implies usage, but no explicit exclusions or alternative comparisons are given.

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

scan_for_log_leaksA

Scan source files for console.log / logger calls that may print environment variables or secrets at runtime. Catches patterns like console.log(process.env.SECRET) or logger.info({ apiKey }) before they reach production logs.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	Absolute path to the project root to scan

TDQS

A3.5/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 the full burden. It mentions what it detects (patterns like console.log(process.env.SECRET)) but does not disclose whether it is read-only, what happens after detection, or the format of results. This lack of output/behavior detail is a significant gap for a security-related 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 consists of two concise sentences. The first states the primary purpose, the second gives concrete examples of patterns caught. No filler or redundant information is present, making it highly efficient and front-loaded.

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?

For a single-parameter tool with no annotations or output schema, the description is reasonably complete in conveying purpose and invocations. However, it lacks any mention of return values or error behavior, which is important for agents to assess results. The examples add value, but the missing output expectations keep it at a middling score.

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?

The schema provides 100% coverage of the only parameter, projectPath, with a description ('Absolute path to the project root to scan'). The tool description adds no additional detail beyond that, so the 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?

The description states a specific verb ('Scan') and resource ('source files') with a clear focus on console.log / logger calls that leak environment variables or secrets. It distinguishes itself from sibling scan_for_secrets by specifically targeting log statements and runtime leaks, not general secret scanning.

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 the tool is used to catch log leaks before production, but it does not explicitly state when to use this over other siblings like scan_for_secrets or provide exclusions. The context is clear enough, but no alternatives are mentioned.

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

scan_for_secretsA

Scan a project directory for hardcoded secrets, API keys, tokens, and passwords. Detects patterns like AWS keys, GitHub tokens, Stripe keys, private keys, and generic high-entropy strings. Returns file path, line number, severity, and a masked preview.

ParametersJSON Schema

Name	Required	Description	Default
`extensions`	No	File extensions to scan, e.g. [".ts",".js",".env"]. Defaults to common source files.
`projectPath`	Yes	Absolute path to the project root to scan, e.g. /project

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses the return format (file path, line number, severity, masked preview) and detection categories, which is useful. However, it does not mention whether the scan is read-only, any permissions required, or limitations like ignored directories, leaving some behavioral aspects unspecified.

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 compact, two sentences long, with the primary purpose front-loaded and additional detail on detected patterns and return values. Every sentence adds value with no redundancy.

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?

Despite lacking an output schema, the description explains what is returned (file path, line number, severity, masked preview). It covers detection scope and examples. Missing some context like hidden files or performance considerations, but overall adequate for a scanner tool of moderate 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 description coverage is 100%, covering both parameters (extensions and projectPath). The description does not add extra meaning 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 uses a specific verb 'Scan' with a clear resource 'project directory' and object 'hardcoded secrets, API keys, tokens, and passwords.' It also differentiates from sibling tools like scan_for_log_leaks by focusing on secrets rather than logs or other scans.

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 when to use (when needing to find secrets in a project directory) but does not explicitly state exclusions or compare with sibling tools. It lacks guidance on when not to use this tool or which alternative to choose for other scanning needs.

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

scan_git_historyA

Scan the git commit history of a repository for secrets that were ever committed, even if later deleted. Detects hardcoded API keys, tokens, passwords, and other credentials added in diff hunks across recent commits. Returns each finding with its commit hash, file, line, severity, a masked preview, entropy score, whether the secret is still present in the working tree, and whether rotation is required. Respects .gitleaksignore.

ParametersJSON Schema

Name	Required	Description
`repo_path`	Yes	Absolute path to the git repository root to scan
`since_days`	No	Only scan commits from the last N days (default: 30)
`last_n_commits`	No	Maximum number of recent commits to scan (default: 50)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses detection method (diff hunks), output fields, and respect for .gitleaksignore. However, it does not explicitly state read-only behavior or potential performance implications of scanning large histories.

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 composed of three efficient, front-loaded sentences. It packs a clear purpose, behavioral details, and a concise list of return fields without any fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives enough detail for an agent to understand the tool's purpose, inputs, and outputs, including severity and rotation status. It lacks explicit failure modes and usage alternatives, but for a read-only scan tool with a well-described schema, it is mostly 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 description coverage is 100%, so the baseline is 3. The description adds context around 'recent commits' which relates to since_days and last_n_commits but does not explain defaults or how the two parameters interact, adding only marginal value beyond the schema.

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 uses a specific verb ('Scan'), specifies the resource ('git commit history of a repository'), and states the exact purpose ('for secrets that were ever committed, even if later deleted'). This clearly distinguishes it from siblings like scan_for_secrets by emphasizing historical commit detection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description sets clear context for when to use the tool (scanning git history for secrets, including deleted ones) but does not explicitly mention alternatives or when not to use it. The sibling differentiation is implied through 'even if later deleted' rather than stated directly.

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.

5 tool updatesv0.2.0Aug 5, 2026
- First observedcheck_gitignore_coverage
- First observedscan_ci_workflows
- First observedscan_for_log_leaks
- First observedscan_for_secrets
- First observedscan_git_history

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

A4/5.0

Scored 2026-08-05 09:50 across 5 tools

Disambiguation5/5

Each tool targets a distinctly different aspect of secret exposure: hardcoded secrets in files, .gitignore coverage, log statement leaks, CI workflow risky patterns, and git history. There is no overlap or ambiguity between them.

Naming Consistency4/5

The verbs are mostly consistent (scan_for_* vs scan_* vs check_*), with scan_ as a common prefix. The inconsistent use of 'for' and the odd one out 'check_' create minor deviation, but the pattern is still recognizable.

Tool Count5/5

Five tools is well-scoped for a secret exposure analyzer. Each tool covers a relevant and non-redundant aspect, and the number is appropriate for the domain.

Completeness5/5

The set covers the primary surface areas for secret exposure: current source code, gitignore protection, runtime log leakage, CI workflow secret handling, and historical git leaks. This provides comprehensive coverage for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

Opzyai Pro
com.opzyai
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Code Analysis Penetration Testing Security
2
secret-scanner A
tools.knurl
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Security Penetration Testing
12
LaunchTrust A
co.launchtrust
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
Security Penetration Testing
92
GitLumen MCP A
io.github.gitlumen-team
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Version Control Code Analysis
52

Related MCP Servers

credential-free
Security Developer Tools Code Analysis
skutry
A
license
Not graded
quality
C
maintenance
Scans code for exposed secrets, API keys, tokens, and credentials across 69 patterns covering cloud services, AI platforms, payment providers, authentication services, and databases.
Updated 9 months ago (2025-12-01 11:44 UTC)
MIT
GuardX
Security Code Analysis
harshzagade
A
license
Not graded
quality
B
maintenance
A keyless, defensive code-security auditor that scans codebases for hardcoded secrets, audits dependencies for known CVEs, and checks passwords against breach data using k-anonymity.
Updated 3 months ago (2026-06-22 18:07 UTC)
1
MIT
opzyai
Security Code Analysis
thfothijn
A
license
Not graded
quality
B
maintenance
Local-first security check for AI coding agents — finds hardcoded secrets, exposed .env files, git-history leaks and vulnerable dependencies (OSV), entirely on your machine. Ask your agent "is this safe to ship?" and get a Launch Readiness score with a fix for every finding.
Updated 2 months ago (2026-07-03 10:07 UTC)
MIT
secrets-audit-mcp
Security Code Analysis
eltociear
A
license
Not graded
quality
B
maintenance
Detects leaked credentials in source code with tools to scan text, files, and directories for API keys, tokens, and private keys across 30+ providers.
Updated 25 days ago (2026-08-19 05:09 UTC)
1
MIT