kr.ai.vdbPublished by vdb.ai.krOfficial publisherv0.2.8Updated Oct 30, 2026
Check packages for CVEs, slopsquatting, and CISA KEV before your AI agent installs them.
VDB lets an assistant check packages, lockfiles and MCP servers for CVEs, slopsquatting and CISA KEV status before installing or recommending them.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/kr.ai.vdb%2Fvdb/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"vdb": {
"type": "http",
"url": "https://vdb.ai.kr/mcp"
}
}
}mcp-name: kr.ai.vdb/vdb
MCP (Model Context Protocol) server for VDB — the AI-aware vulnerability database. Lets Claude Desktop, Claude Code, Cursor, Cline, Continue, and any MCP client check packages while generating code: known CVEs, slopsquatting (LLM-hallucinated package names an attacker may have registered), CISA KEV status, MCP-server trust profiles, and more.
Where this works: Runs where your code is: an agent on your machine with the project folder (Claude Code, Cursor, Cline, Codex CLI). A chat-only web AI cannot use it — its sandbox has no outbound network, and it cannot see your files.
Claude Desktop (claude_desktop_config.json) / Cursor (.cursor/mcp.json):
No install at all — point any streamable-HTTP MCP client at the hosted endpoint:
Claude Code: claude mcp add --transport http vdb https://vdb.ai.kr/mcp --header "Authorization: Bearer $VDB_API_KEY".
The hosted endpoint reads the key from that header (0.2.3+; the
vdbApiToken query parameter Smithery sets still works and takes precedence).
That's it — the server talks to the hosted instance at https://vdb.ai.kr
by default. The package gate (vdb_check_package, vdb_check_packages,
vdb_list_slopsquatting) and the hardening tools (vdb_harden,
vdb_harden_remediate, vdb_harden_verify, vdb_vex) answer without a
key on a per-address allowance (0.2.8+; 100 packages an hour, 3 analyses
an hour and 10 a day, projects up to 200 dependencies, nothing stored). The
other tools need a free API key (https://vdb.ai.kr/signup, or the agent can
request one by email itself: without a key those tools answer
agent_action: REFUSE with a request_key_url). A key is currently unmetered
beyond abuse protection:
The four local-only tools need your files, so the hosted endpoint does not
offer them — seven tools remote, eleven with uvx vdb-mcp.
vdb harden commandThe same package installs the CLI behind the local tools, for use without an MCP client (0.2.2 or newer):
It works without a key (0.2.8+): three analyses an hour and ten a day per
address, nothing stored, upgrades estimated. VDB_API_KEY keeps the project,
re-scores it when a package on a path changes, and signs the evidence.
Where PyPI is unreachable, https://vdb.ai.kr/v1/harden/client.pyz is the
same CLI as one stdlib-only file (hash at /v1/harden/client.sha256):
python3 client.pyz --doctor. Nothing to install.
Sandboxes often allow egress but not name resolution. When — and only when —
resolving vdb.ai.kr fails, the server retries against VDB_API_ADDR. That
bypasses DNS and nothing else: the TLS handshake still presents the real
hostname and validates its certificate, so a pinned connection is exactly as
authenticated as a resolved one. HTTP errors, refused connections and
timeouts are never retried — the name resolved, so the address would be the
same box.
LLMs hallucinate package names; attackers register them (slopsquatting).
LLMs also happily recommend packages with known RCEs. VDB gives your agent a
guardrail: one tool call before npm install / pip install. See
https://vdb.ai.kr/connect for the one-line prompt variant that needs no MCP
at all.
Elastic License 2.0 — free to use, including inside commercial organizations and CI. The only restrictions: you may not offer this software to third parties as a hosted or managed service, or resell it as a product. Commercial licensing beyond that: [email protected]. API usage is governed by the VDB service terms regardless of how you call it.
Source: README.md at commit c57b09f
BEFORE recommending or installing any package, check it here. The response carries `agent_action`: REFUSE (do not add it — relay the `because` text to the user), CONFIRM (ask the user first), or PROCEED. A failed or rate-limited call also answers REFUSE; never proceed unchecked. Also returns the underlying advisories, slop risk, and KEV status as supporting data.
purlrequiredversionBulk-check several packages in one call — always prefer this over repeated vdb_check_package. Each result carries its own `agent_action` (REFUSE / CONFIRM / PROCEED) plus a top-level `agent_action` for the batch. Follow them; relay `because` when refusing. Send names EXACTLY as written — do not correct a typo first, the call is the typo test.
packagesrequiredBEFORE merging, scan the resolved lockfile. Checking the packages someone chose misses the transitive ones nobody did — which is usually where the risk is. Pass the file contents (package-lock.json, requirements.txt, uv.lock, go.sum, Cargo.lock, a CycloneDX SBOM, …). Returns `agent_action`: REFUSE means do not merge.
pathcontentfilenamerequiredFetch a single vulnerability by ID or alias (e.g. CVE-2024-1234, GHSA-xxxx-yyyy-zzzz, VDB-SLOP-…).
idrequiredFree-text search over the VDB vulnerability corpus.
limitqueryrequiredBEFORE recommending a community/unofficial MCP server, check it here. Scope risk is evaluated independently of advisory risk — an unvetted publisher asking for shell or filesystem access is refused even with a clean record. Follow the returned `agent_action`.
server_idrequiredList packages currently flagged as slopsquatting candidates in a given ecosystem.
limitecosystem90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare a license in the repository or the registry entry.
uvx vdb-mcp # or: pipx run vdb-mcp{ "mcpServers": { "vdb": { "command": "uvx", "args": ["vdb-mcp"] } }}{ "mcpServers": { "vdb": { "url": "https://vdb.ai.kr/mcp", "headers": { "Authorization": "Bearer vdb_..." } } }}{ "mcpServers": { "vdb": { "command": "uvx", "args": ["vdb-mcp"], "env": { "VDB_API_TOKEN": "vdb_..." } } }}uvx --from vdb-mcp vdb harden app.py --manifest uv.lock # analyze a call siteuvx --from vdb-mcp vdb harden --doctor # which of network / key / service is at faultuvx --from vdb-mcp vdb harden ./src --manifest uv.lock --vexuvx --from vdb-mcp vdb harden app.py --manifest uv.lock --remediate --target 0.2 # what to fix firstuvx --from vdb-mcp vdb harden ./src --manifest requirements.txt --exclude tests --exclude "*-fixtures"uvx --from vdb-mcp vdb harden app.py --manifest uv.lock --verify P-… --original /tmp/before/app.py # keyless re-verification