Best MCP Servers for Security Research (2026)
A tight shortlist of MCP servers that actually earn a slot in a security research workflow — and the ones that just burn your tool budget.

The best MCP servers for security research are the ones that put a real analysis tool — a disassembler, a graph database, a SAST scanner — behind the model instead of asking the model to guess. That means reverse-engineering bridges like GhidraMCP and Binary Ninja MCP, an Active Directory attack-path server like BloodHound-MCP-AI, a code scanner like SonarQube MCP Server, and a neural web-search server like Exa Search for recon. Below is what each one is for, the trade-offs, and what to leave out so you don't blow past your client's tool limit.
The short answer: five servers, one budget
Start with five servers, not fifteen. Every tool a server exposes gets injected into your model's context on each request, and most clients degrade past roughly 40 active tools — Cursor caps its send list near there for a reason (the math is in Cursor's tool limit, explained). A single server like BloodHound-MCP-AI ships 75+ tools on its own, which is most of your budget in one connection. So the right move is a rotating shortlist, not a permanent load-out.
Here is the working set, by job:
| Server | Job | Why it earns the slot |
|---|---|---|
| GhidraMCP | Reverse engineering | Decompile functions, rename symbols, trace imports/exports/xrefs in Ghidra |
| Binary Ninja MCP | RE / malware triage | Same idea for Binary Ninja users; AI-assisted disassembly |
| BloodHound-MCP-AI | AD attack paths | Query BloodHound graphs in plain English via Cypher-backed tools |
| SonarQube MCP Server | SAST / code review | Pull security, quality, and coverage findings into the agent |
| Exa Search | Recon / OSINT | Neural web search and crawling for CVE and vendor research |
All five run locally over stdio, which matches the wider catalogue — roughly 90% of MCP servers run locally over stdio rather than as remote endpoints. For a security workflow that's a feature, not a limitation: your binaries, graphs, and tokens stay on your box. See local vs remote MCP for when you'd actually want the hosted variant instead.
Reverse engineering: GhidraMCP and Binary Ninja MCP
For reverse engineering, pick the bridge that matches the disassembler you already own. GhidraMCP exposes Ghidra to the model: it can decompile a function, rename symbols, and trace imports, exports, and cross-references — so you can ask "what calls this deobfuscation routine?" and get a real xref answer instead of a hallucinated one.
The value is not that the model reverses the binary for you. It's that it drives the tedious navigation — renaming a hundred FUN_00401abc stubs, chasing a call chain across compilation units — while you keep the judgment.
Binary Ninja MCP is the same trade for Binary Ninja users, aimed at AI-assisted RE and malware analysis. Don't run both. Two disassembler bridges double your tool count for zero gain unless you genuinely switch tools mid-case. GhidraMCP launches a small Python bridge that talks to a running Ghidra server:
{
"command": "python",
"args": ["/ABSOLUTE_PATH/bridge_mcp_ghidra.py", "--ghidra-server", "http://127.0.0.1:8080/"]
}
Keep that server bound to localhost. An MCP bridge that lets a model rename symbols is also a bridge that will happily act on a prompt injected by the very malware you're analyzing — treat decompiled strings as hostile input, not instructions.
Active Directory: BloodHound-MCP-AI
For Active Directory assessments, BloodHound-MCP-AI lets you interrogate an attack graph in natural language instead of hand-writing Cypher. It ships 75+ Cypher-backed tools over the BloodHound graph, so questions like "what's the shortest path from this Kerberoastable account to Domain Admins?" become one prompt.
That 75+ tool count is the catch. Loaded alongside a disassembler and a scanner, it alone can push you over the ~40-tool line where clients start dropping or mis-selecting tools. My rule: enable BloodHound-MCP-AI only during AD work, and turn the RE servers off while it's on.
It connects to your Neo4j-backed BloodHound instance:
{
"command": "python",
"args": ["/path/to/BloodHound-MCP.py"],
"env": { "BLOODHOUND_URI": "bolt://localhost:7687" }
}
Change the default neo4j / bloodhoundcommunityedition credentials before you point anything at it. A graph of your client's entire domain trust is not a database you want on defaults.
Code and web: SonarQube MCP and Exa Search
For code security, SonarQube MCP Server brings SonarQube's security, quality, and coverage findings into the agent, so the model reviews against a real SAST engine's rules rather than vibes. It's SonarSource's own server and runs as a Docker container against SonarQube Server or Cloud — hand it a SONARQUBE_TOKEN and SONARQUBE_ORG and it reads findings; it doesn't need commit access to be useful.
For recon, Exa Search does neural web search and crawling — the right tool for CVE write-ups, vendor advisories, and "who else hit this bug" digging where keyword search falls short. It runs locally via npx with an EXA_API_KEY, or as a hosted remote endpoint if you'd rather not manage the process.
A note on trust: all six of these are community-maintained, not first-party MCP servers from Anthropic. That's normal for the ecosystem, but it means you audit the code before you give it a token or a path to a running disassembler. The security fundamentals are in MCP security: what actually matters.
What to skip
Skip anything that duplicates a tool you already have, and skip broad "do-everything" servers on a security box. Concretely:
- Two disassembler bridges. Run GhidraMCP or Binary Ninja MCP, never both — pure tool-budget waste.
- Write-enabled database servers you don't need. The Supabase MCP Server is a genuinely good SQL/schema server with built-in safety controls, but it belongs in an app-dev stack, not your RE workflow. Don't add SQL write access to a machine whose job is analyzing untrusted binaries.
- Filesystem and shell servers, left always-on. Convenient, but they widen the blast radius of any prompt injection. Enable per-task.
- Remote/hosted servers for local artifacts. No reason to ship a malware sample to a remote endpoint when the stdio version keeps it local.
When you do add one, generate the config from the config generator instead of hand-editing JSON, and browse the full best MCP servers list or the capabilities index if you need a category this shortlist doesn't cover.