Skip to main content
Glama
0pstech

kr.ai.vdb/vdb

by 0pstech

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
vdb_check_packageA

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.

vdb_check_packagesA

Bulk-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.

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 agent_action: REFUSE means do not merge.

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 agent_action.

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 path at the SOURCE TREE, not one file: a not_affected determination is only as wide as the code behind it, and a single-file run withholds them all. Reachability is decided at package granularity from static summaries — good for triage order, not proof of non-exploitability.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 10 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues