Cert-IX MCPs

Prefer a PDF?

Download this guide as a printable, professionally formatted PDF: DepCheck MCP — User Guide (PDF).

MCP servers let an AI coding agent call Cert-IX security tooling directly, as part of its own reasoning loop — no browser, no dashboard, no copy-paste. They speak the Model Context Protocol, the open standard for connecting AI assistants (Claude, Cursor, VS Code, and any MCP-capable client) to external tools.

The first server we offer publicly is DepCheck: a dependency-vulnerability checker that answers, in the moment an agent is about to add or upgrade a package, "is this version safe, and if not, what is?"

Server	DepCheck (vuln-mcp v0.2.0)
Public endpoint	https://mcp.cert-ix.com/depcheck
Transport	Streamable HTTP (MCP) — works with any MCP client
Auth	API key, sent as Authorization: Bearer <key>
Tools	check_package, scan_dependencies, suggest_safe_version, get_advisory, get_cve_intel
Data	OSV (GHSA, Go vulndb, RustSec, PyPA, npm…) + deps.dev, served from the Cert-IX sovereign advisory mirror, enriched with CISA KEV / EPSS exploitation intel

Why an MCP, not just a scanner

Traditional dependency scanners run after the fact — in CI, on a schedule, or when a human remembers to run them. By then the vulnerable package is already committed, and someone has to loop back to fix it.

DepCheck moves the check to the moment of decision. When an AI agent is editing a package.json, go.mod, Cargo.toml, requirements.txt, pyproject.toml, pom.xml, or composer.json, it can ask DepCheck before it writes the version down — and pick a clean version the first time. The vulnerability never enters the tree.

This is exactly how Cert-IX builds its own platform: every coding agent working in the monorepo is instructed to consult DepCheck before adding or pinning any dependency. See Agent workflows for the pattern.

What it is good at

• Point checks — "Is [email protected] on npm vulnerable?" → the advisories that affect exactly that version, plus the minimum safe upgrade.
• Whole-manifest scans — hand it a lockfile or manifest and get back only the vulnerable packages, each with an upgrade target.
• Picking a safe version — the newest release of a package with zero known advisories, so you never hand-pick into a known-bad version.
• Prioritisation — advisories that are exploited in the wild (on the CISA KEV list, or with a high EPSS probability) are flagged and sorted first, so an actively-attacked Medium jumps ahead of a theoretical Critical.
• Advisory detail on demand — full CVSS vector, affected ranges, and references for any advisory ID, to judge whether a finding actually matters for how your code uses the package.

What it is not

DepCheck is deliberately scoped and honest about its edges:

• It checks declared dependencies against published advisory data. It does not execute your code, run SAST/DAST, or analyse your application logic.
• Version ranges (^, ~, >=) are evaluated at their lower bound. To check what is actually installed, scan the lockfile (package-lock.json, Cargo.lock, …), not just the manifest.
• It reports what the advisory databases know today. A "0 vulnerabilities" result means "nothing known as of this lookup", not a guarantee of safety.
• It is a decision aid, not a policy gate. Enforcement (blocking a merge, failing a build) is up to your pipeline — DepCheck gives it the facts.

Supported ecosystems

npm · Go · PyPI · crates.io (Rust) · Maven · RubyGems · Packagist (PHP) · NuGet · Hex (Elixir) · Pub (Dart).

Language aliases like python, rust, and java are accepted as ecosystem names.

Next steps

• Getting started — connect your MCP client to the hosted endpoint in a couple of minutes.
• Tools reference — every tool, its parameters, and example responses.
• Agent workflows — the "check before you add" pattern that keeps a codebase free of known-vulnerable dependencies.
• Security & data handling — auth, rate limits, data residency, and what does (and does not) leave the Cert-IX perimeter.