Skip to main content
Glama

secretguard-mcp

CI Latest release License: MIT

An MCP (Model Context Protocol) server that scans a code string for hardcoded secrets — AWS keys, Stripe keys, GitHub tokens, Google API keys and OAuth client secrets, Slack tokens and incoming webhook URLs, Shopify access tokens, Telegram bot tokens, DigitalOcean tokens, Hugging Face tokens, Notion API tokens, Mailchimp API keys, Postman API tokens, Linear API keys, Readme API keys, Clojars API tokens, Pulumi API tokens, OpenAI keys, Anthropic keys, npm access tokens, SendGrid keys, Twilio API keys, Azure Storage account keys, database connection strings with embedded passwords, private key blocks, JWTs, and generic high-entropy credentials — so an AI coding agent (Claude Code, Cursor, Windsurf, ...) can catch a secret before it writes the file or makes the commit, instead of finding out at CI/PR-review time. It exposes exactly one tool, scan_for_secrets, runs entirely locally over stdio, needs no API key, and never returns a raw secret value — every finding comes back redacted.

Why this exists

secret-scan-action already catches these secrets in CI, on every PR. That's necessary but late — by the time it runs, the secret has already been written, committed, and pushed. This project reuses that same detection engine (same rules, same entropy check, same redaction) but puts it in front of the agent as a tool call, so the check can happen at generation time, before the secret ever touches disk or history.

Related MCP server: classifinder-mcp

What it does

On a scan_for_secrets call:

  1. Splits the input code string into lines.

  2. Runs the same two-tier ruleset secret-scan-action uses:

    • Pattern rules (high confidence) — distinctive formats that are near-certain secrets when matched: AWS access key IDs (AKIA...) and contextual secret keys, Stripe live keys (sk_live_, rk_live_), GitHub tokens (ghp_, gho_, github_pat_, ...), Google API keys (AIza...), Google OAuth client secrets (GOCSPX-...), Slack tokens (xox[baprs]-...), Slack incoming webhook URLs (hooks.slack.com/services/...), Shopify access tokens (shpat_..., shpca_..., shpss_..., shppa_..., shpua_...), Telegram bot tokens (<bot_id>:A..., 35-char secret), DigitalOcean tokens (dop_v1_..., doo_v1_..., dor_v1_..., 64-char hex), Hugging Face tokens (hf_..., api_org_..., 34-char alpha), Notion API tokens (ntn_..., 11 digits + 35 alphanumeric), OpenAI keys (sk-..., sk-proj-..., sk-svcacct-...), Anthropic keys (sk-ant-...), npm access tokens (npm_...), SendGrid keys (SG....), Twilio API keys (SK...), Azure Storage account keys (contextual AccountKey=...), private key blocks (-----BEGIN ... PRIVATE KEY-----), and JWTs. One pattern rule — database connection strings with an embedded password (postgres://, mysql://, mongodb(+srv)://, redis(s)://, amqp(s)://) — is deliberately not near-certain even after excluding known placeholder passwords (user, password, changeit, ...) and ${...}-style env-var references, since a real value there could still be a low-stakes tutorial example rather than a live credential; it's returned at generic confidence, same as the entropy rule below. Another pattern rule — Mailchimp API keys (a 32-char hex value followed by a -usNN datacenter suffix) — is also generic confidence: it only fires when a mailchimp-prefixed variable/key name immediately precedes the value, but that keyword gate still doesn't rule out an unrelated hex value that happens to end in the same suffix shape. Postman API tokens (PMAK-..., 24-char hex + - + 34-char hex), Linear API keys (lin_api_..., 40-char alphanumeric), Readme API keys (rdme_..., 70-char lowercase alphanumeric), Clojars API tokens (CLOJARS_..., case-insensitive, 60-char alphanumeric), and Pulumi API tokens (pul-..., 40-char lowercase hex) are high confidence — a fixed prefix and exact length, same as the other provider-token rules.

    • Generic entropy rule — a value assigned to a variable named like secret, token, password/credential, or a *key compound commonly used for real secret material (apiKey, sessionKey, signingKey, clientKey, webhookKey, ...) whose value also has high Shannon entropy (looks random, not like a placeholder or an env-var reference). Deliberately does not match a bare *Key — that would also catch partitionKey, cacheKey, queryKey, and similar non-secret identifiers common in ordinary code.

  3. Returns every finding's filename, line, ruleId, description, confidence ("high" | "generic"), and a redacted line — the raw secret value never leaves the process. If nothing is found, it returns a plain "No secrets detected." result.

Example output

Calling scan_for_secrets with:

{
  "code": "const key = \"AKIAIOSFODNN7EXAMPLE\";\nconst greeting = \"hello\";",
  "filename": "src/config.ts"
}

returns:

{
  "findings": [
    {
      "filename": "src/config.ts",
      "line": 1,
      "ruleId": "aws-access-key-id",
      "description": "AWS Access Key ID",
      "confidence": "high",
      "redactedLine": "const key = \"AKIA************MPLE\";"
    }
  ],
  "summary": "Found 1 potential secret (1 high-confidence, 0 needs-review).\n\n- [high] src/config.ts:1 — AWS Access Key ID (aws-access-key-id)\n  const key = \"AKIA************MPLE\";"
}

(The AWS key above is AWS's own public documentation placeholder, not a live credential.) A clean scan — e.g. { "code": "const greeting = \"hello world\";" } — returns { "findings": [], "summary": "No secrets detected." }.

Setup

Not yet published to the npm registry — install directly from GitHub via npx. npm install from a git source runs this package's prepare script automatically, which builds dist/ on the fly, so no separate build step is needed.

Claude Code

Add to your project's .mcp.json (or run claude mcp add):

{
  "mcpServers": {
    "secretguard": {
      "command": "npx",
      "args": ["-y", "github:vladimirbakalov/secretguard-mcp"]
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "secretguard": {
      "command": "npx",
      "args": ["-y", "github:vladimirbakalov/secretguard-mcp"]
    }
  }
}

No API key, no account, no config options — restart Claude Code / Claude Desktop and scan_for_secrets is available. The tool description tells the agent to call it before writing code that could contain a credential, and again before a commit or PR — most of the time you won't need to ask for it explicitly.

Cursor / Windsurf

Both read the same command/args shape from their own MCP settings UI or config file — point them at npx -y github:vladimirbakalov/secretguard-mcp the same way.

Once this package is published to npm, the args above can drop to ["-y", "secretguard-mcp"] instead — that's a follow-up, not a blocker.

One-click install (.mcpb)

A prebuilt MCP Bundle is attached to the v0.1.4-mcpb release — download secretguard-mcp-0.1.4.mcpb and open it in Claude Desktop (or any other MCPB-compatible client) for a one-click local install, no npx/Node setup required on the client side. Rebuild it yourself with npm run package:mcpb (see scripts/build-mcpb.sh).

This same .mcpb release asset is what server.json at the repo root points at for the official MCP Registrysecretguard-mcp is published and listed there as io.github.vladimirbakalov/secretguard-mcp, so MCP clients that browse the official registry can discover and install it directly, in addition to the npx/.mcpb paths above. Publishing runs unattended in CI (.github/workflows/publish-mcp.yml) via mcp-publisher login github-oidc on every v*-mcpb tag push — no interactive login step.

Security notes

  • The raw secret value matched by a rule is held in memory only for the duration of a single scan_for_secrets call and is redacted (redactLine/redactSecret) before the tool result is built — it never appears in the returned content, structuredContent, or any log line.

  • The server does no network calls of any kind. It reads stdin, writes stdout (MCP stdio transport), and does nothing else.

  • Generic-tier findings are ambiguous by nature (config placeholders, hashes, and UUIDs can trip the entropy check) — that's expected. Treat confidence: "generic" as "worth a second look," not "confirmed."

Development

npm install
npm run typecheck   # tsc --noEmit
npm test            # vitest run
npm run build       # tsc -p tsconfig.build.json -> dist/

dist/ is not committed — it's built from src/ via the prepare script, which runs both on a git-based npx/npm install and before any future npm publish.

Scope (v1)

One tool, one job: scan a code string, return redacted findings. No allowlist file, no AI triage step, no config options, no persistent state. If this needs any of that later, it'll get added once real usage shows it's needed — not before.

Relationship to secret-scan-action

secretguard-mcp and secret-scan-action share the same detection engine (rules.ts, redact.ts, and the core of scan.ts) but are independent, separately distributed packages: one is a GitHub Action that scans PR diffs in CI, the other is an MCP server that scans arbitrary code strings locally, before a commit exists. Fixing a false positive/negative in the ruleset means updating both.

License

MIT.

Available Tools

1 tool
scan_for_secretsScan for secretsA
Read-only

Scans a code string for hardcoded secrets (AWS keys, Stripe keys, GitHub tokens, Google API keys, Slack tokens, private key blocks, JWTs, and generic high-entropy credentials assigned to secret/token/password/key-like variable names) BEFORE that code is written to a file or committed. Call this proactively whenever you are about to write, edit, or commit code that could plausibly contain a credential — config files, env handling, API client setup, tests with fixture values, or any snippet you're not 100% sure is clean — and again right before creating a commit or PR. Every reported line is redacted; the raw secret value is never returned.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe code to scan, as plain text (one file's contents, or any snippet).
filenameNoOptional filename to attribute findings to (for display only). Defaults to "input".

Output Schema

ParametersJSON Schema
NameRequiredDescription
summaryYes
findingsYes

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint=true annotation, the description reveals a critical behavioral trait: 'Every reported line is redacted; the raw secret value is never returned.' This is exactly the kind of context that helps an agent trust the tool and understand its constraints during use. No contradictions.

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 efficiently structured: first the core action and scope, then explicit use cases, then a security-relevant behavioral note. It is one long paragraph but every sentence earns its place, containing no fluff or repetition.

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?

Given an output schema exists, the description doesn't need to explain return values. It fully covers what the tool does, when to invoke it, and a key behavioral guarantee (redaction). The annotations and schema complement the description to make it 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% and already thoroughly describes both parameters. The description adds no new param-level semantics, though it does reinforce the purpose of 'filename' as display-only in the narrative. Baseline is 3 due to high schema coverage; description adds minimal extra value.

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 opens with a specific verb ('Scans') and a detailed resource: a code string for hardcoded secrets, enumerating many secret types (AWS keys, Stripe keys, GitHub tokens, etc.). This goes far beyond a vague purpose and leaves no doubt about what the tool does.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance is provided: 'Call this proactively whenever you are about to write, edit, or commit code that could plausibly contain a credential' and 'again right before creating a commit or PR.' Specific scenarios (config files, env handling, API client setup, tests) are listed. It also implies using it as a safety net for uncertain code.

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

TDQS

A4.6/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. The purpose is unambiguous.

Naming Consistency5/5

The tool name 'scan_for_secrets' follows a clear verb_noun pattern, consistent with common MCP naming conventions. With a single tool, there is no inconsistency.

Tool Count3/5

A single tool is minimal for a focused secret-scanner server, but feels thin compared to typical MCP servers that offer a broader range of operations. The count is borderline.

Completeness5/5

The tool covers the core functionality of scanning for secrets in code snippets, and no obvious additional operations are needed for this narrow domain. The tool description explicitly addresses proactive scanning before commits, making it self-contained.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • 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.
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Scans text and files for common secrets (AWS, GitHub, etc.) and redacts them to prevent credential leakage in AI-assisted development. Runs entirely locally with no telemetry.
    MIT

Latest Blog Posts

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/vladimirbakalov/secretguard-mcp'

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