The failure is invisible, which is what makes it expensive. Ask any coding agent about a vulnerability and you get an answer shaped by training data, frozen at some point in the past, with no knowledge of exploitation, deadlines, or whether a fix exists. The model answers with exactly the same confidence whether it knows or is reconstructing something plausible, and nothing in the response distinguishes the two. You find out later, from someone else.
One URL, and your agent stops guessing
The Model Context Protocol is how an AI coding agent talks to tools it did not ship with. The entire integration is https://mcp.vulnetix.com/mcp and an Authorization header. There is no daemon, no container, no npx shim and no version to keep current. Protocol revision 2026-07-28 removed sessions from MCP entirely, so the server holds nothing between requests. Twelve clients are verified against the live endpoint, and anything else that can add a remote HTTP MCP server with a custom header works too.
Any MCP server can wrap a CVE API. Six of these tools have no CVE to wrap.
This is not a claim about anyone's roadmap, it is a claim about data. A server built over an advisory feed answers advisory questions well, and end-of-life, malware, detection content, project health and ATT&CK mapping are not advisories. The VDB aggregates 150+ upstream sources, enumerable through the public /v1/sources endpoint, across 4.8M advisory records and 173M affected-version rows.
vulnetix_eol_products
End-of-life products and releases with support dates. Nothing issues a CVE when support ends.
vulnetix_detection_rules
Snort and Suricata signatures, YARA rules and Nuclei templates, returned whole.
vulnetix_scorecard
OpenSSF Scorecard per check, plus maintainer records, provenance and attestations.
vulnetix_iocs
Indicators of compromise, dated sightings and threat-actor attribution, joined to the advisory.
vulnetix_attack_techniques
MITRE ATT&CK techniques, detections and mitigations mapped per advisory.
vulnetix_typosquat_check
Malicious packages with evidence and indicators, plus typosquat candidates.
2.6 MB is not an answer
A raw database record for Log4Shell is 2,606,571 bytes, roughly 650,000 tokens. No context window holds it, and no useful answer requires it. Every response is reduced on the server before it reaches your model: the decision fields survive verbatim (KEV due date, SSVC decision, EPSS, exploitation maturity, remediation timeline, the routines to grep your codebase for) while 676 affected packages become a count and a grouping with a pointer to where the rest can be paged. The default view is 10,613 bytes, 0.41% of the raw record, and every result reports its own ratio.
Porting the shaping layer found bugs in our own filters
The shaping logic is a TypeScript port of the filters the Vulnetix Claude Code plugin runs in production, held to byte-for-byte parity by a differential test over recorded fixtures. It found two real defects in the originals: one filter read a response shape the API does not return and turned an 84 KB response into 83 bytes of nulls; another invented four fields that do not exist while dropping the lifecycle timeline, SSVC decision, severity and KEV entries. Both are fixed upstream, so plugin users benefit whether or not they ever touch MCP. A third defect is documented and deliberately not fixed here: the exploits filter claims to return the most recent exploits but sorts by URL, so the newest ranks last. Correcting it only in the port would make the plugin and the server silently disagree, which is the exact failure the parity test exists to prevent, so it belongs upstream.
No source code leaves your machine
There is no tool that accepts file content, because there is nothing on the other side that could use it. What crosses the wire is a package name, a version, or an advisory identifier. That is also why sixteen of the thirty-three workflows (SAST, secret scanning, SBOM generation, applying a fix) run on your machine through your own agent and the Vulnetix CLI instead of here. The boundary is the guarantee, not a gap waiting to be filled.
An empty list never quietly means "none found"
Everything works on the free Community plan. What a paid plan buys is depth: Community sees exploit and IOC counts, Pro and above see the individual records. Where a plan withholds detail, the counts are still returned and the tool says so explicitly in the response, where your agent reads it too. A security tool that returns an empty array where the honest answer is "19,868, but not on your plan" is worse than one that returns nothing at all.