StackHawk MCP Server: Test and Fix Code Security
Test and fix security issues in your code and Vibe apps with StackHawk's MCP server for fast vulnerability detection and remediation.
npx -y @stackhawk/stackhawk-mcpOverview
StackHawk MCP Server is a lightweight Model Context Protocol (MCP) server designed to accelerate finding and fixing security issues in application code and Vibe apps. It provides a local HTTP service that supplies contextual information—source, dependency metadata, runtime structure—to security scanners and remediation tooling so they can surface high-fidelity findings and, where possible, suggest or apply fixes faster.
Run locally or in CI, the MCP server reduces noisy or incomplete alerts by enriching scans with project-specific context. This makes vulnerability detection more actionable and shortens the feedback loop for developers working on web services, microservices, and frameworks such as Vibe.
Features
- Fast contextualization of code and runtime information to improve scan accuracy
- Local HTTP API that integrates with StackHawk scanners and other security tools
- Works well with Vibe apps and typical web frameworks
- Simple deployment via Docker or source build
- Designed for CI/CD: low overhead, quick startup, and reproducible behavior
- Extensible: can be pointed at different code roots or workspaces for multi-repo environments
Installation / Configuration
Clone the repository and run with Docker, or build from source. The examples below assume a typical Linux/macOS development machine with Docker installed.
Clone repository:
Run with Docker (recommended for local testing):
# Pull the latest image (if published)
# Run the MCP server, exposing port 8080
Docker Compose example:
version: "3.7"
services:
mcp:
image: stackhawk/stackhawk-mcp:latest
ports:
- "8080:8080"
volumes:
- ./project:/workspace:ro
environment:
- MCP_WORKSPACE=/workspace
Build and run from source (if provided in repo):
# Typical Go or Node build steps (replace with actual commands in repo)
Configuration options you will typically set:
- MCP_WORKSPACE: path to the source code or project workspace the server should inspect
- PORT (or MCP_PORT): HTTP port the server listens on (commonly 8080)
- LOG_LEVEL: logging verbosity (info, debug, warn, error)
Always check the repository README or docs for the exact configuration keys supported by the build you’re running.
Available Resources
- GitHub repository: https://github.com/stackhawk/stackhawk-mcp
- Example Docker/Compose manifests in the repository for local testing
- Integration examples (CI snippets) — look for a folder such as examples/ or integrations/ in the repo
- API docs: many MCP deployments publish a small set of HTTP endpoints (status, health, context, analyze). Inspect the running server’s /help or /openapi endpoint if available.
Example API (illustrative)
Many MCP servers expose a small, predictable HTTP surface. Example endpoints you might see:
- GET /health — health and readiness
- GET /status — server version and workspace info
- POST /context — ask the server to produce contextual metadata for a given path or file
- POST /analyze — request a targeted analysis run (used by scanners)
Example: request context for a project file:
Refer to the repository for exact endpoints and request/response schemas.
Use Cases
- Local developer feedback loop
- Run the MCP server on your machine while developing a Vibe app. Point your scanner at the MCP API so results include function-level context and dependency information; this reduces false positives and gives more actionable remediation guidance.
- Pull request security checks (CI)
- Spin up a short-lived MCP server as part of your CI job, mount the PR workspace into the container, run the scanner, and publish structured findings to the PR. Because MCP is lightweight, it adds minimal CI time.
- Pre-scan enrichment for automated fixers
- Use MCP to collect contextual metadata (call graphs, dependency versions, config values) that automated remediation tools can use to propose precise code changes or configuration updates.
- Multi-repo or monorepo scanning
- Configure the MCP workspace to map to specific subprojects so scanners can request only the relevant context for the service under test.
Tips for Developers
- Mount your project as read-only into the MCP container to avoid accidental writes from scans.
- Start with a local experiment: run the server, call the /health endpoint, and then invoke a single context request to confirm the workspace is being indexed correctly.
- Integrate MCP in CI by adding a short-lived container step before your scanner step. Use artifacts or stdout to propagate structured findings.
- If you need to tune results, increase logging (LOG_LEVEL=debug) to see what context is being gathered and adjust workspace mounts or config accordingly.
For implementation details, API schemas, and the latest examples, consult the repository at https://github.com/stackhawk/stackhawk-mcp.