Dcl Webhook vs Guardvibe

A side-by-side look at the Dcl Webhook and Guardvibe MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Dcl Webhook logoDcl WebhookSecurity · Remote HTTP/SSEDeterministic AI audit layer: evaluates LLM/agent outputs against configurable policies (jailbreak, safety, quality, wallet, trade, MEV compliance) and writes every verdict to a tamper-evident SHA-256 hash chain — metadata only, never raw content. 17 tools including a full crypto-trading compliance suite. Pay-per-call via x402 (USDC on Base), from $0.01. mcp.fronesislabs.com/mcp59GoodAuth: not declaredGuardvibe logoGuardvibeSecurity · Local subprocess (stdio)Security MCP for vibe coding with 330 rules and 29 tools. Purpose-built for AI-generated code — scans Next.js, Supabase, Clerk, Stripe, Prisma, Hono, GraphQL, and 25+ modules. Cross-file taint analysis, host security audit, auto-fix, SARIF export, pre-commit hook, and CVE version detection. Zero config, runs locally.65GreatAuth: no auth required

Verdict: choose Dcl Webhook for security work over a hosted endpoint; choose Guardvibe for security as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Dcl Webhook logoChoose Dcl Webhook when

  • You need dedicated capabilities in the Security domain.
  • You prefer a remote HTTP/SSE transport.
  • You want tools like dcl_evaluate_fast, dcl_evaluate_strict, dcl_evaluate_jailbreak.
Explore Dcl Webhook

Guardvibe logoChoose Guardvibe when

  • You need dedicated capabilities in the Security domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like check_code, check_project, get_security_docs.
Explore Guardvibe

Feature & specification comparison

Rows where the two servers differ are marked.

SpecDcl Webhook logoDcl WebhookGuardvibe logoGuardvibe
CategorySecuritySecurity
Quality signal59/100 · Good65/100 · Great
Install commandConfirmedConfirmed
TransportRemote HTTP/SSELocal subprocess (stdio)
AuthNot declaredNo auth required
PricingNot declaredFree
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars16
Directory activity 0 views 0 installs 0 upvotes 3 views 0 installs 0 upvotes
Tools1839

Tools & capabilities

Dcl Webhook tools 18

  • dcl_evaluate_fastFAST Pre-Action Audit ($0.01). Runs the response through the server's "default" policy: a substring check against 3 forbidden phrases ("ignore previous instructions", "jailbreak", "bypass safety") with a 0.7 minimum-confidence threshold. Each forbidden match found costs 0.4 confidence; if confidence falls below 0.7, or any match is found, the verdict is NO_COMMIT and `reason` lists which phrase triggered it. Otherwise COMMIT. Use this as the default low-cost first-pass gate before a risky agent action; switch to dcl_evaluate_strict for a broader, higher-bar check, or to dcl_evaluate_jailbreak / dcl_evaluate_safety / dcl_evaluate_quality for a narrower, single-topic check instead of the general-purpose default policy.
  • dcl_evaluate_strictSTRICT Pre-Action Audit ($0.05). Runs the response against a broader, higher-bar "strict" policy: the union of all forbidden phrases from the default, anti-jailbreak, and safety policies (8 phrases total), with a 0.85 minimum-confidence threshold instead of the default policy's 0.7. Each matched phrase costs 0.4 confidence; if confidence falls below 0.85, or any phrase matches, the verdict is NO_COMMIT with `reason` listing every match found. Use this instead of dcl_evaluate_fast when the cost of a false COMMIT is high — e.g. before an irreversible or high-stakes agent action — since it catches jailbreak- and safety-adjacent phrasing that the plain default policy would miss.
  • dcl_evaluate_jailbreakPRE-ACTION Instruction Adherence Check ($0.02). Runs the "anti_jailbreak" policy: a substring check against 6 forbidden phrases ("ignore previous instructions", "jailbreak", "bypass safety", "pretend you are", "act as if", "DAN") with a 0.8 minimum-confidence threshold — each match costs 0.4 confidence. Returns COMMIT if no phrase matches and confidence stays at or above 0.8, otherwise NO_COMMIT with `reason` listing the matched phrase(s). Use this as a targeted, cheaper check when the concern is specifically prompt-injection / persona-hijack risk; use dcl_evaluate_strict instead when you also want safety- and default-policy phrases covered in the same call.
  • dcl_evaluate_safetyPRE-ACTION Baseline Safety Check ($0.01). Runs the "safety" policy: flags 2 forbidden disclaimers ("I cannot be held responsible", "no guarantees") and additionally REQUIRES the substring "AI" to appear somewhere in the response — missing it costs 0.2 confidence even with no forbidden phrase present. Minimum confidence is 0.75. Returns NO_COMMIT if confidence drops below 0.75, with `reason` naming the forbidden phrase found or the missing required pattern. Use this when you specifically need to confirm an AI-disclosure marker is present and the two disclaimer phrases are absent — not as a general-purpose safety net; for broader coverage use dcl_evaluate_fast or dcl_evaluate_strict instead.
  • dcl_evaluate_qualityPRE-ACTION Content Quality & Drift Check ($0.03). Runs the "content_quality" policy: flags 12 absolutist or unverifiable-claim phrases (e.g. "guaranteed returns", "100% accurate", "studies show", "without a doubt") with a 0.85 minimum-confidence threshold — the highest bar of any single-policy tool. Returns NO_COMMIT if any phrase matches or confidence falls below 0.85, with `reason` listing the matched phrase(s). Use this to catch overconfident or unsubstantiated claims in generated content — a different concern from jailbreak or safety phrasing — e.g. before publishing agent-written copy or reports.
  • dcl_evaluate_secretsPOST-ACTION Secret & Credential Leak Scan ($0.02). Regex-based scan across 8 categories (API keys, cloud credentials, tokens/JWTs, private keys, DB URLs, connection strings, env assignments, webhook secrets, internal endpoints with auth). Any finding results in NO_COMMIT.
  • dcl_evaluate_piiPOST-ACTION PII Detection Scan ($0.02). Regex-based scan across 8 personal-data categories, with a Luhn checksum on card numbers to reduce false positives. Any finding results in NO_COMMIT.
  • dcl_evaluate_batchPRE-ACTION Bulk Processing ($0.10). Evaluates a list of items in one call; each item is a dict shaped {"response": str, "policy"?: str}, where policy defaults to "default" if omitted and may be any built-in policy name (default, strict, anti_jailbreak, safety, content_quality). Each item gets its own independent COMMIT/NO_COMMIT verdict via the same logic as the matching single-item evaluate_* tool; results are returned in input order under `results`, plus a shared `batch_id`. Capped at 200 items per call — oversized batches are rejected. Use this instead of multiple single-item evaluate_* calls when checking several responses — optionally against different policies — in one priced call rather than paying per item separately.
  • dcl_pipeline_startSESSION Management ($0.05). Generates a new `pipeline_id` and returns session metadata (scope, expiry, initial drift_mode) for organizing a series of related checks under one identifier. Note: this call does not currently link the returned pipeline_id to later evaluate_* calls — there is no server-side session state that ties subsequent audits back to it; it is an identifier/timestamp issuer, not an active tracking session. Use this to obtain a shared reference ID for your own client-side grouping of a multi-step audit sequence; do not rely on it to automatically aggregate drift across calls.
  • dcl_audit_decodePOST-ACTION Basic Audit ($0.10). Retrieves a record from the tamper-evident chain by tx_hash.
  • dcl_audit_decode_deepPOST-ACTION Deep Forensic Audit ($0.50). Extended output with drift_context and full chain integrity verification.
  • dcl_evaluate_jailbreak_cryptoPRE-ACTION Crypto Jailbreak & Injection Detection ($0.02). Crypto-specialized instruction-override/jailbreak/injection screen: standard role-switch and instruction-override patterns, plus crypto-specific drain-wallet injection (e.g. "transfer all funds to...", fake "test transaction" requesting full balance) and unlimited-approval injection (e.g. type(uint256).max, "approve unlimited allowance", skip-slippage-confirmation framing). Any match returns NO_COMMIT with `reason` and `findings` naming the matched category/categories; run this FIRST in the DCL crypto pipeline, before wallet/trade/MEV checks, since it screens the input itself rather than a decision built on top of it.
  • +6 more on the listing page

Guardvibe tools 39

  • check_codeAnalyze 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_projectScan multiple files for security vulnerabilities and generate a project-wide security report with a security score. Use this for comprehensive security audits.
  • get_security_docsGet 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.
  • check_dependenciesCheck 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.
  • scan_directoryScan 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_dependenciesParse 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_hallucinated_packagesDetect 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 (definitive hallucination) and brand-new low-download packages (slopsquat-registration pattern). Run on AI-generated code at PR time, before `npm install`. Pass online:false for a fully deterministic, air-gapped scan.
  • scan_secretsScan 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_stagedScan 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).
  • compliance_reportMap 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'})
  • export_sarifScan a directory and export results in SARIF v2.1.0 format for CI/CD integration (GitHub, GitLab, Azure DevOps). Returns JSON string.
  • check_package_healthCheck npm packages for typosquat risk, maintenance status, adoption metrics, and deprecation. Use this before adding new dependencies to catch suspicious or risky packages.
  • +27 more on the listing page

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Dcl Webhook

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "fronesis-labs-dcl-webhook": {
      "url": "https://mcp.fronesislabs.com/mcp"
    }
  }
}

Guardvibe

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "goklab-guardvibe": {
      "command": "npx",
      "args": [
        "-y",
        "guardvibe"
      ]
    }
  }
}

Frequently asked questions

Dcl Webhook is categorized under Security and uses a remote HTTP/SSE transport. Guardvibe belongs to Security and uses a local stdio subprocess. Pick Dcl Webhook for security work and Guardvibe for security.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Dcl Webhook has no declared pricing — check the project's own site. Guardvibe is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add fronesis-labs-dcl-webhook and goklab-guardvibe as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Dcl Webhook has a quality signal of 59/100 (Good) with 0 views, 0 installs and 1 GitHub stars. Guardvibe has 65/100 (Great) with 3 views, 0 installs and 6 GitHub stars.