Local workflows
Every prompt on this server drives your machine rather than the server. They need a repository and the Vulnetix CLI.
That is not a subset any more. There used to be seventeen that ran server-side, and each of them restated a tool sitting next to it — so they were removed, and what remains is only the work a server genuinely cannot do.
Why the split exists
The server is a Cloudflare Worker. It has no filesystem, cannot run a package manager, and cannot invoke Semgrep or Trivy. That is not a gap waiting to be filled. It is the reason no code leaves your machine.
The alternative would be uploading your source to be scanned. Every one of these workflows would then require shipping the thing you are trying to protect to a third party. The boundary is the guarantee.
Install the CLI
curl -fsSL https://cli.vulnetix.com/install.sh | sh
Or by package manager:
brew install vulnetix/tap/vulnetix # macOS / Linuxbrew
scoop bucket add vulnetix https://github.com/Vulnetix/scoop-bucket
scoop install vulnetix # Windows
nix profile install github:Vulnetix/cli # Nix
go install github.com/Vulnetix/cli/cmd/vulnetix@latest
Then authenticate once, with the same credential the MCP server uses:
vulnetix auth login
vulnetix auth status
Full documentation: docs.cli.vulnetix.com.
What each one needs
| Prompt | Needs |
|---|---|
vulnetix_sast_scan | Repo. Optional: Semgrep + .semgrep config |
vulnetix_secret_scan | Repo, or staged changes |
vulnetix_iac_scan | .tf / .tofu / k8s manifests |
vulnetix_container_scan | Dockerfile. Optional: Trivy, Grype, Syft, Docker |
vulnetix_license_check | Dependency tree |
vulnetix_sbom_generate | Repo. Optional: Syft, cosign |
vulnetix_eol_check | Manifests |
vulnetix_fix | Writable manifests, a package manager |
vulnetix_dep_resolve | Package manager (npm ls, cargo tree, …) |
vulnetix_verify_fix | Repo, for the re-scan gate |
vulnetix_vex_publish | .vulnetix/memory.yaml. Optional: gh |
vulnetix_dependency_choice | Manifests, and a conversation with you |
vulnetix_repo_impact | Repo, for the dependency graph |
vulnetix_typosquat_check | Manifests |
vulnetix_detection_rules | Somewhere to write the rules |
vulnetix_exploit_test | An authorised target. Optional: Nuclei |
vulnetix_secure_code_write | The file you are editing |
vulnetix_dashboard | .vulnetix/memory.yaml only |
Third-party binaries are optional augmentation, never requirements. The CLI
has its own scanners; Semgrep, Trivy, Grype, Syft and cosign compose with them
when present. vulnetix agent capabilities writes .vulnetix/capabilities.yaml
recording what it found, and these workflows read it to decide what to offer.
That detection was a prompt until it became a CLI command, which is also when it
started working on Windows.
Which agents can run these
The prompt tells your agent to run shell commands, so the agent needs to be able to.
| Client | Can run them |
|---|---|
| Claude Code | Yes, Bash tool |
| Cursor, Windsurf | Yes, agent mode terminal |
| VS Code / Copilot | Yes, agent mode terminal |
| Cline, Roo Code | Yes |
| Continue, Goose | Yes |
| Zed | Yes, agent panel terminal |
| Claude Desktop | No, no shell and no repository |
In Claude Desktop these prompts still render, and are still readable as a procedure, but nothing will execute. Use a terminal-based agent.
Shared state
Several workflows read and write .vulnetix/memory.yaml in your repository,
holding tracked findings, triage decisions and history. It is the CLI’s file, and
the MCP server never sees it.
vulnetix_dashboard reads it and nothing else, which is why it works with no
network at all.
If you only want the intelligence
You do not have to install anything. All 31 tools work with nothing but the MCP connection, and they cover every lookup — a CVE, its exploits, its KEV status, a package’s advisories. The prompts are for when you want the workflow around that intelligence, and they are never a precondition for it.