Cert-IX MCPs
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.
Three servers are available publicly today, and each has a distinct job:
- DepCheck is the developer entry point. It checks dependency versions for known vulnerabilities while your agent edits a manifest, and it is useful on its own: the key is free and self-service, and you do not need a Cert-IX account.
- SecCheck gives your agent a written procedure for security and compliance work, drawn from three open-source playbook libraries and served through one searchable endpoint.
- Bits helps you adopt the Cert-IX host agents. It recommends one, explains it, gives you a download you can verify and drafts a configuration for you to review. It needs no key, and it deploys nothing.
The servers
| DepCheck | SecCheck | Bits | |
|---|---|---|---|
| Answers | "Is this dependency version safe — and if not, what is?" | "How is this security or compliance task actually done?" | "Which Cert-IX agent fits this machine, and can I verify the download?" |
| Endpoint | https://mcp.cert-ix.com/depcheck | https://mcp.cert-ix.com/seccheck | https://mcp.cert-ix.com/bits |
| Auth | API key — free, self-service | API key — free, self-service (Community edition) | None — public |
| Tools | 5 | 7 | 5 |
| Content | Published advisory data (OSV, GHSA, Go vulndb, RustSec…) enriched with CISA KEV / EPSS | 857 playbooks curated from three open-source libraries | The public release catalogue, with a verifiable SHA-256 per download |
| Docs | Getting started | SecCheck overview | Bits overview |
All three use Streamable HTTP and all three are read-only — they look things
up and return them; none mutates your project or your systems. DepCheck and
SecCheck authenticate with an API key sent as Authorization: Bearer <key>;
Bits needs no key at all and answers anonymously.
Which one do I need?
- Your agent is editing manifests — adding, pinning or upgrading dependencies → DepCheck.
- Your agent is doing security work — threat hunting, incident response, detection engineering, a pentest step, a control implementation, an audit preparation → SecCheck.
- Your agent is evaluating or installing a Cert-IX host agent — which one fits, which binary to fetch and how to verify it, how to configure it → Bits.
Using them together
They answer different halves of the same job. When an agent hardens a service, SecCheck supplies the procedure it should follow and DepCheck vets every dependency version that work introduces. One is method; the other is fact-checking. Neither substitutes for the other.
DepCheck
Download the DepCheck guide as a printable, professionally formatted PDF: DepCheck MCP — User Guide (PDF).
DepCheck is the developer entry point to Cert-IX: 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?" It works on its own — the API key is free and self-service, and no Cert-IX account is needed.
| 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> — free and self-service |
| Tools | check_package, scan_dependencies, suggest_safe_version, get_advisory, get_cve_intel |
| Data | OSV advisories (GHSA, Go vulndb, RustSec, PyPA, npm…), served first from Cert-IX's own advisory mirror and enriched with CISA KEV / EPSS exploitation intel. When the mirror cannot answer, lookups fall back to the public osv.dev API, and version lists come from deps.dev — with package coordinates only. See Security & data handling. |
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.
DepCheck documentation
- Getting started — get a free key and 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.
SecCheck
SecCheck gives an AI agent a written procedure to follow for security and compliance work — offensive testing, defensive detection and response, and GRC — instead of letting it improvise from whatever it half-remembers. The agent searches the library, loads the playbook that fits, and follows it. Because the playbook is a document, you can read it too, and check the agent's work against it.
Most playbooks state when to use them and what you need first, then give the steps in order; many also include verification or validation criteria. The format varies by library: the GRC playbooks are organised by task (gap analysis, policy drafting, risk assessment), and the PentesterFlow ones as a numbered test methodology.
Where the content comes from. The 857 playbooks are curated from three
open-source libraries published under the Apache-2.0 and MIT licences;
get_attribution returns the full
attribution and licence texts. What Cert-IX adds is the delivery to your agent:
one hosted endpoint, search across all three libraries, filters by category and
framework, framework-tagged results, and editions tied to your API key.
| Server | SecCheck (security-skills v2.2.1) |
| Public endpoint | https://mcp.cert-ix.com/seccheck |
| Transport | Streamable HTTP (MCP) — works with any MCP client |
| Auth | API key, sent as Authorization: Bearer <key> — free and self-service for the Community edition |
| Tools | list_sources, search_skills, load_skill, list_skill_resources, read_skill_resource, license_status, get_attribution |
| Content | 857 playbooks across 3 open-source libraries — 745 defensive, 69 offensive, 43 compliance, mapped to MITRE ATT&CK / D3FEND, NIST CSF, ISO 27001, SOC 2, GDPR, PCI DSS and more |
What it is good at
- Finding the right procedure fast — by keyword, category (offensive / defensive / compliance), framework, or tag.
- Framework-anchored compliance work — gap analysis, control implementation, evidence collection and document drafting against a named standard.
- Both sides of a technique — the attack playbook and the detection playbook live in the same library, which is exactly what you need to prove a control actually fires.
- Grounding an agent that would otherwise improvise — a loaded playbook is a specification you can hold the agent to, and read yourself.
SecCheck documentation
- SecCheck overview — what it holds, the three libraries, and the editions.
- Getting started — get a free key and connect your MCP client, or run it locally over stdio.
- Tools reference — all seven tools, their parameters, and real example responses.
- Agent workflows — the search → load → follow discipline.
- Security & data handling — auth, entitlements, rate limits, and data residency.
Bits
Bits helps you adopt the Cert-IX host agents — bitcollector, bitscanner, bitenforcer and bitmapper. It advises and prepares; it never acts on your estate. Ask it, and it will:
- recommend the agent that fits a goal — including "none of these do" when that is the honest answer;
- explain what an agent observes, what it never touches, and what running it with or without privilege changes;
- give you a verifiable download — the version, file size, SHA-256 and a command that fetches the binary and checks it;
- draft a configuration for a human to review, together with what it deliberately will not do.
| Public endpoint | https://mcp.cert-ix.com/bits |
| Transport | Streamable HTTP (MCP) — works with any MCP client |
| Auth | None — public and anonymous |
| Tools | bits_recommend, bits_explain, bits_platforms, bits_plan_config, bits_download |
| Content | The public Bits release catalogue, plus a reviewed table of what each agent does and never does |
Bits has no access to your tenant or your hosts, holds no credential, and deploys
nothing. Enrolling an agent uses a token generated in your Cert-IX dashboard, and
that token belongs on the machine the agent runs on — never in the MCP:
bits_plan_config and bits_download refuse any argument shaped like one.
Bits documentation
- Bits overview — what it answers, and what it will not tell you.
- Getting started — connect your MCP client; no key needed.
- Tools reference — all five tools, their parameters, outputs and failure shapes.
Cette page vous a-t-elle été utile ?