Mmcp.market

Guardvibe MCP server

by goklab·io.github.goklab/guardvibe·v3.34.1

Deterministic security layer your AI can't be. 472 rules, 39 tools, CLI + doctor + host audit.

C58/100grade C
What users say
No reviews yet
Be the first
Safety scan
C58/100

full report

Adoption
Growing

5 stars63 downloads/wk

Reviews

Write one

Nobody has reviewed Guardvibe yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Guardvibe tools (42)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • analyze_cross_file_dataflow

    Track user input flowing across module boundaries — detects injection vulnerabilities spanning multiple files. Pass files array with file contents. For single-file analysis, use analyze_dataflow instead. Example: analyze_cross_file_dataflow({files: [{path: 'src/api.ts', content: '...'}, {path: 'src/db.ts', content: '...'}]})

  • analyze_dataflow

    Track user input (request body, URL params, form data) flowing into dangerous sinks (SQL queries, eval, file operations, redirects). Detects injection vulnerabilities that regex rules miss by following variable assignments through code.

  • audit_config

    Audit application config files (next.config, middleware, .env, vercel.json) for cross-file security gaps: missing headers, unprotected routes, exposed secrets. NOT the same as guardvibe_doctor which checks AI host security (MCP configs, hooks). Example: audit_config({path: '.'})

  • audit_mcp_config

    Scan MCP configuration files (.claude/settings.json, .cursor/mcp.json, .vscode/mcp.json) for security issues: malicious hooks (CVE-2025-59536), suspicious MCP servers, overly permissive tool access, and shell injection patterns. Use this to verify MCP configurations are safe before use.

  • auth_coverage

    Analyze authentication coverage across Next.js App Router routes. Detects auth guards (Clerk, NextAuth, Supabase, custom) and reports protected vs unprotected routes. Pass files array with route file contents and middleware content. Example: auth_coverage({files: [{path: 'app/api/users/route.ts', content: '...'}], middleware: '...'})

  • check_code

    Analyze inline code for security vulnerabilities (OWASP Top 10, XSS, SQL injection, insecure patterns). Pass code as a string parameter. For scanning files on disk, use scan_file instead. Example: check_code({code: 'app.get(...)', language: 'javascript'})

  • check_command

    Analyze a shell command for security risks before execution. Returns allow/ask/deny verdict with blast radius, safer alternatives, and context-aware risk assessment. Detects: destructive ops, git history rewrites, secret exposure, data exfiltration, deploy triggers, privilege escalation, database drops.

  • check_dependencies

    Check npm, PyPI, or Go packages for known security vulnerabilities (CVEs) using the OSV database. Use this before adding new dependencies or to audit existing ones.

  • check_package_health

    Check npm packages for typosquat risk, maintenance status, adoption metrics, and deprecation. Use this before adding new dependencies to catch suspicious or risky packages.

  • check_project

    Scan multiple files for security vulnerabilities and generate a project-wide security report with a security score. Use this for comprehensive security audits.

  • compliance_report

    Map security findings to compliance controls (SOC2, PCI-DSS, HIPAA, GDPR, ISO27001, EUAIACT). Scans a directory and groups issues by control. Output includes a summary section at the top; for large projects, findings are truncated to top 50. Use mode=executive for C-level summary. Example: compliance_report({path: '.', framework: 'SOC2'})

  • deep_scan

    LLM-powered deep security analysis for vulnerabilities that pattern-matching cannot detect: IDOR, business logic flaws, race conditions, stale auth, mass assignment, privilege escalation. Defaults to Claude Haiku 4.5 (~cents per scan); pass `model: 'sonnet'` for deeper analysis at higher cost. Requires ANTHROPIC_API_KEY or OPENAI_API_KEY env var.

  • explain_remediation

    Pass a GuardVibe rule ID (e.g. VG154) to get a detailed explanation: risk assessment, exploit scenario, minimum fix, secure alternative, and test strategy. Optionally pass the affected code snippet for context-aware guidance. Example: explain_remediation({rule_id: 'VG402'})

  • export_sarif

    Scan a directory and export results in SARIF v2.1.0 format for CI/CD integration (GitHub, GitLab, Azure DevOps). Returns JSON string.

  • fetch_page
  • fetch_weather

    Returns weather for a given city

  • fix_code

    Pass vulnerable code as a string and get fix suggestions with before/after patches. Returns structured edit instructions (line numbers, severity, confidence). Use verify_fix afterwards to confirm the fix resolved the issue. Example: fix_code({code: '...', language: 'typescript'})

  • full_audit

    Single command that runs ALL checks: code scan (429 rules), secret detection, dependency CVEs, config audit, taint analysis, and auth coverage. Returns PASS/FAIL/WARN verdict with deterministic hash. IMPORTANT: If verdict is FAIL or WARN, you MUST call remediation_plan next to get a section-by-section fix checklist — do NOT skip any section. After fixing, call verify_remediation to confirm ALL sec

  • generate_policy

    Auto-detect project stack (Next.js, Supabase, Stripe, Clerk, Prisma, etc.) and generate tailored security policies. Outputs ready-to-use CSP headers, CORS configuration, Supabase RLS policies, rate limiting rules, and security headers based on detected frameworks.

  • get_security_docs

    Get security best practices and remediation guidance for a specific topic, framework, or vulnerability type. Covers OWASP Top 10, framework-specific hardening (Next.js, Supabase, Stripe), and secure coding patterns. Returns actionable guidance with code examples.

  • get_user

    Fetch user record by id

  • guardvibe_doctor

    Check AI host security: MCP configurations, hooks, base URL hijacking, environment variable exposure. NOT the same as audit_config which checks application config files (next.config, .env, headers). Use scope=project (default) for project-only, scope=host to include shell profiles and global AI configs. Example: guardvibe_doctor({scope: 'project'})

  • policy_check

    Check project against compliance policies defined in .guardviberc. Use this in CI/CD pipelines to enforce security gates, or before releases to verify compliance requirements are met. Validates custom framework requirements, severity thresholds, required controls, and risk exceptions. Returns pass/fail status with detailed findings per control.

  • remediation_plan

    Generate a mandatory section-by-section remediation plan from full_audit results. MUST be called after full_audit when verdict is FAIL or WARN. Returns ordered steps for ALL 6 sections (secrets, code, dependencies, config, taint, auth-coverage) with specific tool calls and actions. AI assistants MUST complete every section — skipping sections is not allowed. Example: remediation_plan({path: '.'})

  • repo_security_posture

    Analyze a repository's overall security posture. Maps sensitive areas (auth, payments, PII, admin, API, infrastructure), identifies high-risk workflows, recommends guard mode, and lists priority fixes.

  • review_pr

    Review a pull request for security issues. Scans only changed lines (diff-only mode) and produces output for GitHub Check Runs, PR comments, or inline annotations. Supports severity gating to block PRs.

  • scan_changed_files

    Scan only files that have changed since a given git ref (branch, commit, or HEAD~N). Ideal for PR checks, pre-push hooks, and incremental CI. Diff-aware by default: returns only findings on newly-added lines (set diff_aware:false for whole changed files).

  • scan_config_change

    Compare before/after versions of a config file to detect security downgrades: CORS relaxation, CSP weakening, HSTS removal, debug mode, cookie flag changes, TLS disabling, new hardcoded secrets, removed security headers.

  • scan_dependencies

    Parse a lockfile or manifest (package.json, package-lock.json, requirements.txt, go.mod) and check all dependencies for known CVEs via the OSV database. Reads the file directly. Use this after installing dependencies, during CI, or when auditing existing projects for vulnerable packages.

  • scan_directory

    Scan all files in a directory on disk for security vulnerabilities. Pass a directory path — reads files from filesystem. Returns security score (A-F) and findings. Results may be truncated for large projects — check fileRanking in JSON output for top files. Example: scan_directory({path: './src'})

  • scan_file

    Scan a single file on disk by path for security vulnerabilities. Pass a file path — the tool reads the file itself. For inline code snippets, use check_code instead. The 'agent' format returns the structured guardvibe.agent.v1 contract (finding + exact edit + confidence + verify step). Example: scan_file({file_path: 'src/api/route.ts', format: 'agent'})

  • scan_hallucinated_packages

    Detect AI-hallucinated and slopsquatted packages in a repo — the supply-chain seam commodity SCA misses. OFFLINE (deterministic): flags phantom imports (a package imported in source but absent from every package.json — a classic LLM hallucination tell) and typosquats of popular packages. ONLINE (opt-in, default on; gracefully degrades offline): adds npm-registry truth — packages that return 404 (d

  • scan_host_config

    Scan host environment for AI security issues: API base URL hijacking (CVE-2026-21852), credential exposure in shell profiles, .env file leaks, and environment variable sniffing. Checks .env files at project scope; add scope=host to also check shell profiles and global AI configs.

  • scan_secrets

    Scan files and directories for leaked secrets, API keys, tokens, and credentials. Detects high-entropy strings, known API key patterns (AWS, Stripe, OpenAI, GitHub, Supabase), exposed .env files, and missing .gitignore coverage. Returns findings with exact line numbers and remediation steps.

  • scan_secrets_history

    Scan git history for leaked secrets. Finds secrets that were committed in the past — even if they were later removed. Marks each finding as 'active' (still in code) or 'removed' (in git history only, needs rotation).

  • scan_staged

    Scan git-staged files for security vulnerabilities before committing. Run this before every commit to catch issues early. No input needed — automatically reads staged files. Diff-aware by default: reports only issues on newly-staged lines (set diff_aware:false for whole staged files).

  • secure_prompt

    Shift-left security at the prompt level: analyze a raw coding prompt BEFORE any code is written and return a structured enhancement directive that embeds GuardVibe security requirements (auth checks, input validation, webhook signature verification, SQL injection prevention, secrets handling) into the prompt you are about to execute. Deterministic — no LLM, no network: triage verdict NO_MOD (promp

  • secure_this

    Close the loop on vulnerabilities in code: scan, apply only the fixes that VERIFIABLY land (each candidate edit is re-scanned and rolled back if it fails to resolve the issue or introduces a new one), and return the verified code plus a definition-of-done gate. Prefer this over fix_code+verify_fix when you want a guarantee the fix landed — not just a suggestion. Returns { status: clean|secured|par

  • security_stats

    Show cumulative security statistics, grade trend, and vulnerability fix progress for this project. Use this to demonstrate the value of GuardVibe security scanning over time. Data is stored locally in .guardvibe/stats.json.

  • security_workflow

    Get the recommended GuardVibe tool sequence for your current task. Returns which tools to call, in what order, and with what parameters. Use this when unsure which tool to use. Example: security_workflow({task: 'pre_commit'})

  • verify_fix

    Verify that a specific security fix was applied correctly. Re-scans the updated code and checks if the target vulnerability (by rule ID) is resolved. Returns 'fixed', 'still_vulnerable', or 'new_issues' status with details.

  • verify_remediation

    Compare before/after audit results to verify ALL sections were addressed. MUST be called after completing remediation to confirm success. Runs a fresh audit and compares against the before snapshot. Explicitly flags skipped sections and refuses to return 'complete' status unless every section is addressed. Pass the before audit hash or let it re-run. Example: verify_remediation({path: '.', before_

Public scan report

scanner v0.1.9 · 2026-09-22 · same rubric, same numbers if you re-run it

1 high2 medium
  • Code scan213 source files scanned3/25
  • Live reliabilityno gateway calls yet and no remote to proben/a
  • Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 0 days ago15/15
  • Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Findings (3)

  • highWhole environment serialized (possible credential exfil)env.dump
    build/data/rules/ai-tool-runtime.js: …eturn { content: [{ type: "text", text: JSON.stringify(process.env) }] };', compliance: ["SOC2:CC6.…
  • mediumsubprocess with shell=Trueexec.shell-true
    build/data/rules/core.js: …s.run([...]) with list arguments, never shell=True with user input.", fixCode: "//…
  • mediumeval / new Function usedexec.eval
    build/tools/cross-file-taint.js: …e-injection": "Never pass user input to eval() or Function constructor.", "co…
Overall 58/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

What the publisher says

From the Guardvibe repository's README, as published. We do not edit it. Read it on GitHub

GuardVibe

Security infrastructure your AI can't be.

No matter how good your coding agent gets, it can't know the CVE published after its training cutoff, it can't deterministically guarantee the same check every run, it can't hold your whole repo in context, and it can't objectively review its own code. GuardVibe does all four — the deterministic, post-cutoff-current, whole-repo, author-independent verification layer for AI-written code.

  • 🗓️ Knows what your AI doesn't. CVE rules refreshed daily from GHSA / OSV.dev / CISA KEV — GuardVibe flags vulnerable dependencies published after your model's training cutoff. (97 CVE rules, npm run intel daily triage.)
  • 🎯 Deterministic, not probabilistic. Same code = same result, every run (content-hashed). Your AI guesses; GuardVibe doesn't.
  • 🗺️ Sees the whole repo. Cross-file taint + auth-coverage across every route — catches the unprotected endpoint your agent's narrow context missed.
  • 🔍 An independent second pair of eyes. The thing that wrote the code can't review itself. GuardVibe is the outside checker on AI-written code — in the loop while your AI codes (real-time edit hook), not after.
  • ⬅️ NEW: Starts before the first line of code. Every scanner on earth — including your agent reviewing itself — acts after the code exists. secureprompt acts before*: it analyzes the coding prompt itself, detects the stack and attack surfaces it implies, and embeds severity-ranked GuardVibe requirements into the prompt your AI executes. The vulnerability is prevented, not caught. Deterministic, zero LLM calls — and if the prompt is already secure, it passes through untouched.

The security MCP built for vibe coding. 472 security rules, 39 tools covering the entire AI-generated code journey — from the prompt itself to production deployment.

Works with Claude Code, Cursor, Gemini CLI, Codex, VS Code (Copilot), Windsurf, and any MCP-compatible coding agent.

Why a tool, when your AI is so good?

"More rules" was never the moat — a strong model already knows most security rules by heart. What it can't do is be deterministic, know the CVE published after its training cutoff, hold your whole repo in context, or objectively review the code it just wrote. Those four gaps are structural; they don't close as models improve. GuardVibe is the layer that fills them — running while your AI codes, not in a separate audit later. And since v3.19, it runs before your AI codes too: secure_prompt rewrites the task itself so the security requirements are in the prompt, not in the post-mortem.

Why GuardVibe

Most security tools are built for enterprise security teams. GuardVibe is built for you — the developer using AI to build and ship web apps fast.

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

Install directly

Runs npx -y guardvibe on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add guardvibe -- npx -y guardvibe
Add to Cursor

Guardvibe: common questions

Is Guardvibe MCP server safe?
With care: it is graded C, so read the findings first (58/100). Read the Guardvibe safety report
How do I install Guardvibe?
It runs on your machine. Copy the Claude Code, Claude Desktop or Cursor config from the install section.
Does Guardvibe need an API key?
Not as far as the registry entry and our scan can tell: no credentials are declared or required.
Is Guardvibe maintained?
The last commit was in the last day (2026-09-22). The latest release is v3.34.1.
What can I use instead of Guardvibe?
Servers from other publishers that do the same job: CodeInspectus MCP server, npm Registry MCP Server and SPARDA MCP server. Compare all Guardvibe alternatives.

Alternatives to Guardvibe

Same job from other publishers: the closest match first, then the best rated.

All Guardvibe alternatives →
  • CodeInspectus
    Local-first MCP security scanner and CLI for AI-generated applications.
    C
  • npm Registry MCP Server
    npm registry MCP server — package intelligence, security audits, dependency analysis
    B
  • SPARDA
    AI writes. SPARDA proves. Deterministic, offline security gate for AI edits.
    A
  • grim-mcp
    Security audit for AI agents: code, deps, exposure, secrets, drift, SBOM, and IoC.
    C
  • Security Txt Cra Lint
    13 rules that decide whether a vulnerability report ever reaches you
    A

More from goklab