Keel

Name: Keel
Author: LLM Mart

No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.

Thirteen MCP tools. Semantic dedup. Per-host rate limits. Safe proofs that show what a hunter can do — without damaging the target.

Why Keel · Install · Clients · Proofs · Tools

Dumping 150 tools on an agent is easy. The hard problems are dedup across tools, exploitable vs noise, and not hammering the target. Keel is the control plane for those three.

An AI client talks to Keel, not to httpx, nuclei, or a shell. Keel drafts one wave at a time, enforces scope and rate limits, merges scanner hits into semantic cards, and runs GET-only playbooks on tester-owned data. When a playbook returns proven, you get a curl replay a hunter can follow — still without writes, shells, or payload spam.

Use it on programs you are authorized to test.

Why Keel

Hard problem	What scanner dumps do	What Keel does
Dedup across tools	One Nuclei template id per row; the same IDOR appears five times	Semantic key from vulnerability class + normalized route + method + parameter. UUID/id/hex tokens collapse. Compatible observations merge.
Exploitable vs noise	High severity = "ship it"	Cards move through `observed` → `hypothesis` → `corroborated` → `proven` / `refuted`. Informational and hardening stay hidden. Typed exploitability names the missing evidence and the negative control.
Not hammering the target	Fire every template at once, retry on 429	One active wave per host, token buckets, Nuclei concurrency 1, no OAST, no redirects, no unsigned templates, no dos/fuzz/bruteforce/intrusive tags. HTTP 429 becomes a cooldown.

A wrapper that shells out to a huge toolbox does not have that layer. Keel does — in the scheduler, in the adapters, and in the proof broker.

Architecture

flowchart TD
    A[AI coding client] -->|stdio MCP| B[Keel]
    B --> C[Scope and rate gate]
    C --> W[Background job and wave scheduler]
    W --> H[httpx: one target]
    W --> N[nuclei: HTTP templates, bounded]
    C --> P[Proof broker: GET only]
    P --> T[Tester-owned resource]
    H --> S[Semantic card store]
    N --> S
    P --> S
    S --> Q[Triage and evidence states]

begin_engagement with the hostname you are authorized to test.
draft_waves proposes reachability plus template micro-waves. No traffic yet.
execute_wave returns a job immediately. Poll wave_status. cancel_wave kills the scanner.
query_cards returns hunter-relevant cards. assess_exploitability says what would prove it.
draft_proof then execute_proof run a GET-only playbook against tester data. proven means the invariant held. protected means the control worked.

Installation

macOS (Homebrew). pipx is a separate tool — install it first. Apple's /usr/bin/python3 is often 3.9 and cannot install Keel.

brew install pipx python@3.12
pipx ensurepath
# open a new terminal, then:
pipx install keel-pentest
keel-pentest setup
keel-pentest doctor

If python3.12 is already on the machine and you do not want Homebrew pipx:

python3.12 -m pip install --user pipx
python3.12 -m pipx ensurepath
python3.12 -m pipx install keel-pentest

setup downloads ProjectDiscovery httpx and nuclei into ~/.keel/bin. Keel finds them there even when a GUI client has a thin PATH. No extra KEEL_HTTPX_BIN for a first scan.

Then point your MCP client at the keel-pentest executable:

claude mcp add --scope user --transport stdio keel -- keel-pentest
codex mcp add keel -- keel-pentest
hermes mcp add keel --command keel-pentest

OpenCode: "command": ["keel-pentest"].

Python 3.10+. Do not pip install keel — that is a different project. OS notes and pip/venv: INSTALL.md. Client shapes: clients/README.md.

Why Keel

Architecture

Installation

Related servers