The VibeLock MCP server

Hosted, not installed#

The server is hosted by VibeLock and reached over HTTPS. There is no local package to install and nothing on your machine to keep updated. You connect once, approve it on a sign-in consent screen, and choose the app it scans for.

Connecting#

Claude Code

Install the VibeLock plugin. It bundles the scan skill and connects to the hosted server. Sign in and approve when prompted.

Cursor

Add the VibeLock server in Cursor’s MCP settings. It is the same server and the same scan. Sign in and approve when prompted.

Anything else

Lovable, Bolt and other builders connect through read-only GitHub instead. See Connections.

Exact setup steps are published when VibeLock opens.

What the scan looks at#

• Dependencies with known vulnerabilities.
• Secrets in the code.
• Routes missing authentication.
• Injection patterns, such as queries built from strings.
• Database access rules, such as row level security left off.

What VibeLock receives#

Findings, not source. The scan runs on your machine, inside your coding tool, and sends VibeLock what it found: the check, the result, where it was found and why. Your code stays with you.

The tools#

The server gives your coding tool three tools. A scan is one call to start, your coding tool reading the code on your machine, and one call to submit.

vibelock_start_scan

Starts a scan of your code at the commit you are on. VibeLock sends your coding tool the list of security checks to look for, written as plain instructions, and a one-time pass for this scan that expires after two hours. Nothing leaves your machine at this step but the commit id.

vibelock_submit_scan

Sends back what your coding tool found, once per scan: for each check, pass, fail or not sure, where in the code it looked, and a sentence of explanation. It never sends code or secret values, and VibeLock rejects the whole batch if anything looks like either, so your tool can correct it and send again.

vibelock_get_findings

Lists your open findings, most urgent first, with where each one is and its deadline. On paid plans each finding comes with a fix prompt your coding tool can follow. Your coding tool shows you the change and makes it only when you ask.

The pass for each scan is signed by VibeLock, so a submission can only answer the checks that scan issued, at the commit it was started on. That signature is VibeLock’s own receipt of what it issued. It proves nothing about the tool on the other end, which is why a scan from your coding tool is never enough on its own.

Why results count as self-reported#

A scan that runs on your own machine is useful, and it is also input VibeLock cannot see being produced. So bad news is believed and good news is corroborated. A single report from your coding tool can never clear an earlier failure.

A failed check

Believed straight away. It becomes a finding with a severity and a deadline, and a critical counts against the badge at once.

A passed check

Marked self-reported. It starts counting only when a second scan at least ten minutes later agrees, at the same code with no uncommitted changes, or when VibeLock’s outside scan confirms it.

Not sure

Counts for nothing either way. It is an honest answer, and better than a guess.

Tokens and limits#

• One token per app, so a connection can never reach another app.
• Revocable at any time; a revoked token stops working at once.
• Rate limited: a scan can be started six times an hour.

What it will never do#

VibeLock never writes to your code, through MCP or any other path. It explains findings and writes fix prompts; your coding tool makes a change only when you ask it to.