Scans local Express apps for security issues such as wildcard CORS, string-built SQL, shell injection, and API routes that mutate data without an auth check.
Detects open Firebase security rules in the scanned project.
Scans local Next.js projects for common security problems, including secrets exposed to the browser through NEXT_PUBLIC_ variables, API routes that change data without a visible auth check, and dangerous code patterns such as dangerouslySetInnerHTML.
Flags Supabase tables without row-level security and leaked Supabase service_role JWTs found in the scanned project.
Scans local Vite projects for secrets exposed to the browser through VITE_ environment variables, alongside other leaked-secret and unsafe-code findings.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@repo-security-scan-mcp scan ./my-app for security issues before launch"
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.
An MCP server that lets Claude (or any MCP client) triage a local project for the classic security problems in AI-built web apps (Next.js, Vite, Express, Supabase, Firebase and similar).
It reads a folder you point it at. It never opens network connections and never probes live sites. Secrets in results are redacted to their first 4 characters.
Leaked secrets (AWS, Stripe, GitHub, OpenAI/Anthropic-style, Slack, SendGrid, private keys, database URLs with passwords, JWTs including Supabase service_role), secrets exposed to the browser through NEXT_PUBLIC_/VITE_ variables, Supabase tables without row-level security, open Firebase rules, wildcard CORS, dangerous code patterns (eval, dangerouslySetInnerHTML, string-built SQL, shell injection), API routes that change data without a visible auth check, weak JWT secrets, weak password hashing, debug mode left on, TLS verification turned off, committed .env files, unpinned dependencies, missing lockfile and missing tests.
Related MCP server: opzyai
Tool | What it does |
| Scans a folder; returns counts and findings ordered by severity ( |
| Same scan, returned as a short plain-English go/no-go with what to fix first. |
Requires Node 18+ and Python 3.
git clone <this repo> && cd repo-security-scan-mcp
npm install
npm testAdd to Claude Desktop (claude_desktop_config.json) or Claude Code (claude mcp add):
{ "mcpServers": { "repo-security-scan": { "command": "node", "args": ["/absolute/path/to/server.mjs"] } } }Set PYTHON if your Python executable is not python (Windows) or python3 (macOS/Linux).
Then ask: "Scan ./my-app and tell me what to fix before launch."
This is a heuristic static scan, not a penetration test. It produces false positives and misses issues. Review each finding before acting, and rotate any exposed secret immediately. npm test runs a real MCP client against generated fixture apps (fake secrets are assembled at runtime so this repo never contains token-shaped strings): 7 checks, including "clean app has 0 HIGH findings".
Open an issue or message the author.
License: MIT
Scans a local project folder (Next.js, Vite, Express, Supabase, Firebase style) for leaked secrets, secrets exposed to the browser, missing Supabase row-level security, wildcard CORS, open Firebase rules, dangerous code patterns and API routes without a visible auth check. Returns counts plus findings ordered by severity. Secrets are redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or relative path to the project folder | |
| limit | No | Maximum findings to return | |
| max_mb | No | Skip files larger than this many MB | |
| min_severity | No | Hide findings below this severity | LOW |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so the safety profile is covered; the description goes beyond them by disclosing the detection categories, the shape of the result (counts + severity-ordered findings), and that secrets are redacted — an operationally important trait. It stops short of noting scan cost, file-count limits, or that nothing is written to disk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and scope, then a dense but useful enumeration of checks; the second sentence delivers the return contract and the redaction guarantee. The category list is long but each item is a distinct, decision-relevant signal, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden and does it well by summarizing return shape and ordering. What remains unsaid — error behavior on a missing/invalid path, whether large repos are truncated — is modest for a read-only scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so path, limit, max_mb, and min_severity are already documented in structured form. The description adds no format or semantics for these (e.g., how min_severity interacts with the ordering, or what max_mb skips), which is the expected baseline when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (scans) plus a precisely scoped resource (a local project folder, with example frameworks) and an explicit enumeration of what it hunts for. The output contract ('returns counts plus findings ordered by severity') makes it unmistakable against the sibling triage_summary, which cannot be a scanner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and the path requirement, but the description never states when to reach for this versus triage_summary, nor any prerequisite (e.g., that the path must be locally accessible, or that it is a point-in-time static scan rather than a live check). Adequate context, no explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the same scan and returns a short plain-English triage: what to fix first and why. Good for a quick go/no-go before deploying.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the project folder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower. The description adds real value beyond them by characterizing the return: short, plain-English, prioritized as "what to fix first and why." It does not mention latency, size limits, or determinism of the text, but the output shape disclosure is substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler; the purpose and the deploy-time use case are front-loaded in that order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must carry the return-value burden, and it does reasonably well by describing the triage as a prioritized plain-English summary. The only gap is the unspecified relationship to scan_repo, which an agent would need to reason out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema fully documents "path." The description adds no format or constraint detail beyond that, which is the expected baseline when the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and output ("returns a short plain-English triage: what to fix first and why") and implies a relationship to the sibling by saying it "runs the same scan." It stops short of naming scan_repo as the alternative, so the distinction from that sibling is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Good for a quick go/no-go before deploying" gives a concrete usage context, which is more than nothing. But it never states when to prefer this over scan_repo, nor any exclusions (e.g., use the raw scan when you need details, not a summary).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0scan_repotriage_summaryScored across 2 tools
scan_repo and triage_summary both run 'the same scan', so their boundaries are blurry; the distinction is purely output format (raw findings by severity vs. plain-English prioritization). An agent wanting a prioritized answer versus full findings has some guidance, but the overlap invites misselection.
Both names use snake_case and are readable, but scan_repo is a clear verb_noun while triage_summary is a noun phrase (verb/domain mix). Minor deviation within an otherwise consistent style.
Two tools for a full security scanner is on the thin side. The scan/summarize pair covers the headline workflow, but there is no room for narrower operations like scanning a single file or listing rule metadata.
Core scan-and-report is present, but notable gaps exist: no way to fetch details for a single finding, filter/ignore rules, manage a baseline, or run in a CI-oriented mode. Agents can work around these by re-running scans, but the lifecycle is partial.
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Scan a deployed app URL for exposed keys, open Supabase tables and missing security headers.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Scan a site or AI-built app for exposed databases, keys and MCP endpoints, then verify the fixes.
