shinthink/blitzstrikeMCP server packaging a three-tier penetration-testing methodology: attack-surface reconnaissance, source-to-sink static analysis, and live finding validation with escalation chains.
Reconnaissance at speed. Analysis in depth. Validation before report.
Blitz Strike is a structured penetration-testing methodology — reconnaissance,
source analysis, and validation — delivered as a universal MCP server. It
enumerates the attack surface (BLITZ), traces source-to-sink reachability
(EAGLE-EYE), and verifies each finding live before it is reported (STRIKE).
One server, every agent: scope enforcement to submission-ready findings in a
single run_engagement call, with the relevant exploit-tool manual attached to
every result.
A scan hit is a hypothesis. A live test is the verdict.
Blitz Strike exists to eliminate the two most common failure modes in automated security assessment: false positives from surface-level pattern matching, and unverified findings reported without live confirmation.
Blitz Strike is a Model Context Protocol (MCP) server (TypeScript / Bun) that
packages a 3-tier security-audit methodology as callable tools — and runs the
whole engagement server-side, so a single run_engagement call works from
Claude Code, Cursor, Hermes, OpenCode, Claude Desktop, Gemini, or any MCP client.
Blitz Strike maps a structured penetration-testing methodology — reconnaissance, source analysis, and validation — into three tool tiers executed server-side.
| Tier | Name | Phase | What it does |
|---|---|---|---|
| 1 | BLITZ | Reconnaissance & attack-surface mapping | Enumerates the exposed attack surface at scale: unauthenticated entry points, dangerous sinks, and authentication boundaries. |
| 2 | EAGLE-EYE | Static analysis & data-flow tracing | Traces source-to-sink reachability and enriches findings against the escalation-chain graph. Confirms a sink is reachable, unauthenticated, and exploitable — not merely present. |
| 3 | STRIKE | Validation & exploitation | Performs live verification (marker reflection + negative control), scope enforcement, and orchestration so a finding is confirmed before it is ever reported. |
Reconnaissance → analysis → validation. Nothing is reported until STRIKE confirms it.
Beyond the three tiers, Blitz Strike also ships Web3 audit (deterministic Solidity + executable Foundry proof), a live logic-bug prober (sibling enumeration + differential IDOR), hunting intel (CWE/CVE watchlist + DNS sinkhole detection), and out-of-band proof — so IDOR/auth logic bugs, blind injection, and smart-contract findings are all caught and proven, not just pattern-matched.
Blitz Strike is driven by the LLM — Claude, Hermes, OpenCode, Codex, or any MCP client. The LLM is the brain (plans, routes, delegates, judges); Blitz Strike is the deterministic hands + knowledge + guardrails.
A full engagement is one call, or a granular agent-orchestrated cycle:
npx blitzstrike serve --mcp # connect your agent, then ask it to
# "audit ./src" (source) or "audit https://example.com" (live)
The LLM classifies the target automatically (URL → live pipeline, filesystem
path → source pipeline), then drives recon → analyze → verify → review →
report — guided by the bundled doctrine (instructions + skills + per-step
next_steps) and fanned out across the platform's native sub-agents.
→ Autonomy & doctrine — how the LLM is steered.
bun build --compile — ship one executable per platform.bunx blitzstrike / npx blitzstrike.@modelcontextprotocol/sdk).# Zero-install — works from any MCP client, no clone, no build
npx -y blitzstrike doctor # verify the environment
npx -y blitzstrike install # auto-register with every detected agent CLI
npx blitzstrike install detects every installed agent CLI (Claude Code,
Cursor, OpenCode, Codex, Hermes, Gemini, Windsurf, Copilot, Cline) and writes
the correct MCP config to each one in its native format. Restart your agent and
call run_engagement.
From source:
git clone https://github.com/shinthink/blitzstrike.git
cd blitzstrike
bun install
bun run src/index.ts serve --mcp
{
"mcpServers": {
"blitzstrike": {
"command": "blitzstrike",
"args": ["serve", "--mcp"]
}
}
}
claude_desktop_config.json or .mcp.json.cursor/mcp.json.mcp.jsonmcp_servers: in config.yamlRun blitzstrike install to print the exact snippet.
blitzstrike serve --mcp # start MCP server over stdio (default)
blitzstrike doctor # health check: runtime + 130-tool catalog + creds
blitzstrike install # write MCP config to detected clients (Claude/Cursor/OpenCode)
blitzstrike install --dry-run # preview the config without writing
blitzstrike sync-data # fetch heavy datasets (payloads + templates) on-demand
blitzstrike update # check for a newer version + refresh the data cache
blitzstrike version # print version
| Check | Status you'll see |
|---|---|
| Runtime (bun/node) | OK / FAIL + fix |
| Security tools catalog | 63/130 installed, 67 on-demand |
| FOFA credentials | OK / WARN + fix |
| Data layers (chains + tools-catalog) | present / missing |
Each issue carries a fix: line — no guessing.
blitzstrike install detects which MCP client config files already exist
(Claude ~/.claude.json, Cursor ~/.cursor/mcp.json, project .mcp.json) and
merges the Blitz Strike server entry in — it never overwrites your existing
MCP servers. With no client detected, it prints the snippet for manual paste.
| Tool | Purpose |
|---|---|
blitz_scan(path, max_files) | Scan a source tree: enumerate unauth entry points + dangerous sinks with file:line refs. |
blitz_file(path) | Same scan, single file. |
| Tool | Purpose |
|---|---|
eagle_eye(path, symbol) | Return a function's full body, sinks in scope, and auth gates in scope. |
eagle_grep(path, sink, max_hits) | Precision sink grep — report a hit ONLY inside a function body, flagged guarded/un-guarded. |
enrich_scan(path, max_files) | Scan + match detected sinks to escalation chains (chains.json). |