Metasploit Deep Dive Part 12: msfmcpd, Rapid7's Own MCP Server

This part was originally scoped as a reangle problem. AI Part 7 already covered wiring an LLM into Metasploit through MetasploitMCP, a community Python project talking to msfrpcd over MessagePack RPC. Writing the same integration twice wasn’t going to add anything, so this part needed a genuinely different angle to justify existing.

Then, while researching Part 1’s release history, that problem solved itself. Metasploit Framework 6.5, released July 30, 2026, less than a week before this post was drafted and about five weeks after AI Part 7 published, shipped msfmcpd: a first-party Model Context Protocol server built directly into the framework by Rapid7. This isn’t a reangle anymore. It’s a genuinely different, more current story, and it’s worth comparing against both AI Part 7’s community-tool approach and this site’s own MCP server directly, since all three represent different answers to the same underlying question: how much should you let an AI agent do to a system with real consequences.

What msfmcpd is, from its own real source

msfmcpd (repo root, a real executable) is a Ruby process that loads msf/core/mcp and runs Msf::MCP::Application.new(ARGV).run. Reading lib/msf/core/mcp/ directly shows the architecture: an application.rb that parses config and CLI flags, a rpc_manager.rb that auto-detects, auto-starts, and manages the lifecycle of an msfrpcd process underneath it, and a server.rb implementing the actual MCP protocol surface, named msfmcp per the real source. The official architecture diagram in Rapid7’s own wiki puts it plainly: an AI application talks MCP (stdio or HTTP) to the MCP layer, which talks to an RPC manager, which talks to a Metasploit API client, which talks to the real msfrpcd, the exact daemon Part 11 just read source for.

Sixteen tools total, split into two enforced categories.

Twelve read-only tools, on by default: msf_search_modules, msf_module_info, msf_host_info, msf_service_info, msf_vulnerability_info, msf_note_info, msf_credential_info, msf_loot_info, msf_module_results, msf_running_stats, msf_session_list, msf_session_read. Every one of these queries the framework’s database or job state; none of them can change anything.

Four dangerous tools, off by default, gated behind an explicit flag: msf_module_execute, msf_module_check, msf_session_stop, msf_session_write. These require --enable-dangerous-actions on the CLI, MSF_MCP_DANGEROUS_ACTIONS=true as an environment variable, or mcp.dangerous_actions: true in the config file, three separate ways to opt in and zero ways to end up enabled by accident.

The gating model is the actual story

This is where msfmcpd earns a direct comparison to this site’s own MCP server, described in Ansible Deep Dive Part 13: Claude doesn’t get a raw shell on Herald, it gets narrow, typed tools like write_site_file and deploy_post, each one scoped to a specific allowed action. msfmcpd takes a related but distinct approach: it doesn’t shrink the tool surface itself, sixteen tools is a broad surface, covering nearly everything a human operator would do at msfconsole. Instead, it splits that surface into a default-safe tier and an explicitly-opted-into dangerous tier, with the dangerous tier requiring active operator intent at startup, not per-call approval. msf_module_execute will run any of the roughly 5,000 modules Part 1 counted, with arbitrary datastore options, once dangerous mode is on; there’s no per-module allowlist inside the MCP layer itself. The safety boundary is coarse (all four dangerous tools, together, gated as one switch) rather than fine-grained (each individual module or action separately reviewed), which is a meaningfully different tradeoff than this site’s own narrow-tool model, and worth naming honestly rather than treating one approach as simply better than the other. A coarse on/off gate is easier to reason about and audit (“dangerous mode was enabled during this engagement, full stop”). A narrow per-action tool surface is safer by default but requires the tool author to have anticipated every legitimate action in advance, which a general-purpose offensive framework with 5,000 modules genuinely cannot do the way a personal site’s fixed deploy workflow can.

Rate limiting (default 60 requests/minute, configurable burst), Bearer token authentication for the HTTP transport (auto-generated if not set, loudly printed to the console on startup so an operator can’t miss it), and file logging with sanitization round out the operational safety story. None of these are novel ideas in isolation, but seeing them shipped as defaults on a tool this consequential, by the vendor themselves rather than a third party, is a genuine signal about where Rapid7 thinks this is heading.

Compared to AI Part 7’s community approach

AI Part 7’s stack was: msfrpcd started by hand, MetasploitMCP as a separate Python process translating msgpack RPC into MCP tool calls, mcpo bridging a transport mismatch between MetasploitMCP’s SSE output and Open WebUI’s Streamable HTTP expectations, and Open WebUI itself as the client. Four moving parts, three of them third-party, none of them built or maintained by Rapid7. msfmcpd collapses that entire chain into one first-party binary that manages its own msfrpcd lifecycle automatically. It’s a smaller number of moving parts, an officially maintained trust boundary instead of a community one, and a dangerous-actions gate that MetasploitMCP’s twelve-tool surface, per AI Part 7’s own accounting, didn’t implement as a first-class concept the same way. The community project got there first by five weeks. The vendor’s version, once it landed, landed with a more deliberate safety model than the thing it’s replacing.

What this doesn’t resolve

A safety gate at the MCP layer is not the same thing as safety at the model layer. Nothing about msfmcpd’s dangerous-actions flag stops an operator from enabling it and then handing an agent a prompt broad enough to make its own targeting decisions across all 5,000 modules once the gate is open. The gate controls whether the capability exists at all, not how it gets used once it does, and AI Pentest Agents Part 8 already asked the harder version of this question, whether the human pentester still has a job, at the level of judgment rather than tooling. msfmcpd is a better-engineered on-ramp to that same open question, not an answer to it.

Part 13 finishes the RPC-adjacent material this and Part 11 have been building toward: the database layer underneath msf_host_info, msf_credential_info, and the rest of the read-only tools this post just walked through, workspaces, loot, and how Metasploit tracks what it’s already found.