From twelve tools to a hunt: the MCP playbook

We shipped twelve tools. Then we watched how they actually get used, and the gap between having tools and getting value is the entire reason a playbook exists. This is how we came up with it.

The cardinal sin, the one we saw again and again, is using a vulnerability-intelligence MCP as a CVE search box: a status-code and severity-number checker. The tools will happily serve that. But the usage that treats them that way leaves the differentiated capability untouched, reaching for the plain lookups and skipping the part that actually finds bugs. The playbook is the accumulated operating knowledge of turning the tools into landed findings instead of lookups, written against exactly that failure.

The thesis: what the MCP is for

It is a memory of real mechanics to borrow and run, not a lookup. The value is three things a stateless reasoner cannot generate for itself:

Watched over time. Priors, temporal signal, exploitation calibration. What a model cannot know from a single prompt.
Seen many. A corpus of disclosed bug-bounty reports plus CVE mechanisms, so an unfamiliar target can be matched to a bug proven elsewhere.
Live-fused recon. observe recovers a host's real backend identity and endpoints from its JS bundles, then joins them to CVE data.

The job is not done when a tool returns a number. It is done when you have transferred a mechanic onto the target and executed it, or read a fix to falsify an option. Everything in the playbook serves that line.

Not all tools are equal

The first thing the playbook does is rank the tools by where they add irreducible value, because treating twelve tools as a flat menu is how a hunt collapses into lookups. The split is stark:

The differentiated tools are the ones a reasoning agent cannot replicate on its own: observe (live recon that recovers a backend an SPA hides from header-fingerprinting), find_attack_approaches and find_continuations (mechanism transfer and position-to-move orientation from the disclosed-report corpus), assist_submission (transfers the winning submission techniques from accepted reports), hunt_plan (ranks an internal stack for chaining), and program_outcome_prior (a minute-zero, program-specific bug-class prior).
The commodity tools are real but replaceable: search_vulns, check_technology, enrich_cve, corpus_stats. The CVE data underneath is public, and a capable agent can drive these itself. They confirm a version range or pivot by mechanism; they are not the discovery engine.

This is not a knock on the commodity tools. It is a warning. The natural gravity of the interface pulls an agent toward the lookups, and the playbook exists to counteract that gravity: lead with recon and transfer, use the lookups to confirm, never mistake the lookup for the hunt.

The loop, in order

Select a winnable target. Target selection beats drill depth. Web and network-heavy scope with self-hosted software, not a mobile-app or WAF fortress.
Recon with a browser user agent, then observe each live host. It is async: poll until it returns ready, then mine the whole response (endpoints, recurring loci, internal hosts, exploitation signal), not two fields.
Version-match with check_technology or hunt_plan.
Run verify_cve_claim before any claim. It catches your own over-claims, including a product-name mismatch even when the version is in range.
enrich_cve for feasibility. Read the mechanism (POST versus GET, auth required) to judge whether a chain is even possible.
Transfer and execute. find_attack_approaches hands you source, sink, and trigger; run those moves on the target, do not cite them. Loop with a growing tried= so each round surfaces the moves you have not tried yet.
When stuck, find_continuations. Describe your product-free attacker state and get the concrete payload-bearing step the card compresses away, then immediately cross-check the class against the target with search_vulns.
assist_submission at the end. Execute the submission techniques it returns; do not just cite a precedent for a severity number.

The disciplines you only learn by losing time

The value map and the loop are the easy part. The disciplines are the part that was paid for in wasted probes, and they are the reason the playbook reads like a field manual instead of a spec:

A browser user agent is call number one. A default curl user agent is bot-blocked, and many CDN and WAF "Access Denied" 403s are user-agent rules, not walls. A browser UA plus Accept headers routinely reopens several times the surface on estates you would wrongly call hardened. It does not bypass real origin blocks, app-WAF on payloads, or auth, and knowing that boundary is half the discipline.
Read the fix to falsify, do not fire blind probes. Before blasting a target with a hypothesis, pull the patch commit or the source and check feasibility. A fix that is a dependency bump to an HTTP-only fetcher makes a file:// SSRF architecturally impossible: killed in two reads instead of a hundred blind probes.
Transfer and execute, never cite for severity. The corpus hands you the technique, how it was proven, framed, and escalated. The finding becomes submission-ready by running that technique on the target, not by citing the precedent for a number.
Do not over-parallelize. The server has a small worker pool; bursting heavy calls cascades into timeouts. One heavy call at a time.
Know which side of the sandbox wall you are on. Unauthenticated recon primes, culls, and strengthens submissions, then walls at exploitation: the paying bugs (broken object-level authorization, payment logic, auth) live behind a real session. Stop expecting an unauthenticated P1 from a fortress.

And underneath all of it, the discipline that is the whole edge: verify before you claim. The playbook catalogs the recurring shapes where a non-finding looks like a finding, each with the single check that settles it. Version-in-range is not exploitable until the precondition is confirmed. A reachable 200 can come from an SPA catch-all on the wrong host, so confirm which origin served the bytes. A leaked API key is only a finding if it does something. Your summary of a source-read is not the bytes, so read the actual call chain. And your own confidence number has a stake in the answer, so have something with no stake re-score it. The phantom judgment relocates one layer deeper every time you secure a layer, and the fix is to attach every claim to the cheapest check that kills it.

Honest economics

The playbook is candid about the ceiling on purpose. Even expert engagements mostly land P2 to P4: a blind SSRF capped by its blindness, an unrestricted API key worth a few hundred dollars, an access-control issue. The P1s are usually open leads, credential hunts that need auth or a non-frontend secret leak, not landed findings. The MCP sharpens where and how to strike and what not to waste time on. It does not grant access, and a playbook that pretended otherwise would waste your time in a more expensive way.

How we came up with it

The playbook is a kill log. The per-tool gotchas and the false-positive checks were each learned by losing time to them: the product-name mismatch that a version check missed, the SPA catch-all that read like a finding, the CONFIRMED written off a summary that the raw bytes refuted. We wrote each one down with the check that would have saved the hour.

The value map itself came out of a deliberate method rather than opinion. We ran an A/B agent-selection test on the tool set: when several tools competed for the same slot, an agent picked worse, so we folded the redundant discovery tools into one and kept the set lean. The rule we settled on is to fold a tool only where a selection test shows real friction, and otherwise to serve full facts and let the reasoning agent decide, never pre-digesting a fact into a verdict.

It pairs with the bug-hunting skill, which handles the thinking and the honesty, while the playbook handles the tools. Both are MIT-licensed and public, and the playbook stands alone: you can drive the MCP from it without the skill, though you will hunt better with both.

FAQ

What is the vuln-intel MCP playbook? It is the operating manual for driving the vulntel vulnerability-intelligence MCP on a real bug-bounty hunt: a per-tool value map, the loop to run the tools in order, and the disciplines that separate landing a finding from running CVE lookups. It is MIT-licensed and public.

Why do I need a playbook if the tools are self-explanatory? Because the interface pulls you toward the wrong use. The natural way to use a vulnerability MCP is as a CVE search box, which leaves the differentiated capability, transferring a proven attack mechanic onto your target and executing it, untouched. The playbook exists to counteract that gravity and turn the tools into findings.

Which tools matter most? The differentiated ones a reasoning agent cannot replicate itself: observe for live recon, find_attack_approaches and find_continuations for mechanism transfer, assist_submission for submission technique, and hunt_plan for chaining. The lookup tools (search_vulns, check_technology, enrich_cve) are useful but replaceable, since the CVE data under them is public.

What is the difference between the playbook and the skill? The skill is cognition and discipline, how to think like an attacker and stay honest, independent of any tool. The playbook is about driving the MCP's specific tools: which one earns its call, in what order, and the gotcha that bites you if you skip a step.

Is it open source? Yes. The playbook and the skill are MIT-licensed and public in the vuln-intel-mcp repository.

The MCP playbook and the bug-hunting skill are MIT-licensed and public; they drive the vulntel MCP, whose twelve tools you can see with live examples. Related field notes: the bottleneck for AI security agents, why memory and discipline beat a bigger model; why you can't turn a pull-based MCP into a push model, which is why deep hunts need a persistent memory the playbook points to; and the flagship guide, vulnerability intelligence for AI agents.