kr.ai.vdb/vdb
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| vdb_check_packageA | BEFORE recommending or installing any package, check it here. The response carries |
| vdb_check_packagesA | Bulk-check several packages in one call — always prefer this over repeated vdb_check_package. Each result carries its own |
| vdb_scan_lockfileA | BEFORE 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 |
| vdb_lookupA | Fetch a single vulnerability by ID or alias (e.g. CVE-2024-1234, GHSA-xxxx-yyyy-zzzz, VDB-SLOP-…). |
| vdb_searchC | Free-text search over the VDB vulnerability corpus. |
| vdb_check_mcp_serverA | BEFORE 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 |
| vdb_list_slopsquattingB | List packages currently flagged as slopsquatting candidates in a given ecosystem. |
| vdb_hardenA | Decide whether attacker-controlled data can reach a dangerous operation through this file's transitive dependencies — with no CVE required. Use it on code that passes user input into a third-party API. The file is abstracted LOCALLY first (identifiers renamed, literals reduced to shapes, bodies dropped); only that abstraction and the lockfile are sent, never source text. Returns decided paths, a call-site fix that does not modify the dependency, and the residual risk the fix does not cover. |
| vdb_harden_verifyA | After applying a fix returned by vdb_harden, re-abstract the local file and verify the originally issued path. Returns a signed evidence payload bound to the original analysis, the fixed IR fingerprint, and the dependency graph. This proves VDB's decision over the submitted abstraction, not that the abstraction matches a deployed binary. |
| vdb_vexA | Given a project directory and its lockfile, work out which of its known advisories can actually be reached by attacker-controlled data, and return an OpenVEX document plus a shareable URL. Use this when a scan produced more findings than anyone can triage. Point |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool has a clearly distinct purpose: single vs bulk package checks, lockfile scanning, vulnerability lookup vs search, MCP server vetting, slopsquatting listing, harden analysis, post-fix verification, and VEX generation. Even the two checking tools are cleanly separated by input cardinality and workflow stage. No ambiguity about which tool to select for a given task.
All tool names follow the consistent `vdb_` prefix with snake_case verb_noun or verb patterns (e.g., check_package, scan_lockfile, harden_verify). The naming makes the action and target predictable across the entire set, with no style mixing or vague verbs.
Ten tools is well within the ideal range for a vulnerability database and supply-chain security server. Each tool earns its place by covering a distinct stage—package vetting, bulk checks, lockfile analysis, lookup/search, MCP server risk, and remediation—without redundant or filler tools.
The tool surface provides full lifecycle coverage: check packages, scan lockfiles for transitive risk, look up and search vulnerabilities, vet MCP servers, list slopsquatting candidates, run reachability analysis, verify fixes, and generate VEX documents. There are no obvious gaps or dead ends for the stated domain.