Bridging Burp Suite and Claude AI: Inside PortSwigger’s MCP Server Extension

Hook

What if your AI assistant could interact with your web security testing proxy through natural conversation? PortSwigger just made this possible by implementing the Model Context Protocol in Burp Suite.

Context

Security professionals have long used Burp Suite as their go-to web application security testing platform, while AI assistants like Claude Desktop have become increasingly capable. But these tools existed in separate worlds—until now. The Model Context Protocol (MCP), developed by Anthropic, provides a standardized way for AI systems to interact with external tools and data sources. However, MCP clients like Claude Desktop only support stdio transport (standard input/output), while desktop applications like Burp Suite are better suited to running persistent web servers. This architectural mismatch created a barrier: how do you connect a stdio-only AI client to a desktop application that needs to maintain state across multiple requests? PortSwigger’s MCP Server extension solves this by implementing a dual-architecture approach—an SSE (Server-Sent Events) server running inside Burp as an extension, plus a packaged stdio proxy that bridges the transport gap. This allows security professionals to leverage LLM capabilities directly within their existing Burp workflows through conversational interfaces.

Technical Insight

The extension’s architecture elegantly solves the transport mismatch problem through layered components. At its core, the extension runs an SSE MCP server directly within Burp Suite on localhost port 9876 by default. This server exposes Burp’s functionality as MCP tools that LLMs can invoke. The clever part is the packaged stdio proxy server—a separate JAR that Claude Desktop spawns as a child process, which then forwards requests to the SSE server. Here’s what a Claude Desktop configuration looks like:

{
  "mcpServers": {
    "burp": {
      "command": "/path/to/burp/java",
      "args": [
        "-jar",
        "/path/to/mcp-proxy-all.jar",
        "--sse-url",
        "http://127.0.0.1:9876"
      ]
    }
  }
}

This configuration tells Claude to launch the Java proxy, which maintains a persistent connection to Burp’s SSE endpoint. When Claude needs to interact with Burp, it writes to the proxy’s stdin, the proxy translates this to HTTP requests against the SSE server, and responses flow back through stdout. This design keeps Burp’s extension simple (just an HTTP server) while satisfying Claude’s stdio requirement.

The extension is written in Kotlin and follows a clear pattern for tool definitions. All tools are defined in src/main/kotlin/net/portswigger/mcp/tools/Tools.kt as serializable data classes, with tool names auto-derived from their parameter classes. The framework includes built-in pagination support—tools that extend a Paginated interface automatically handle large datasets by chunking results, potentially useful for scenarios where proxy history or scan results might contain many entries.

The configuration surface is intentionally minimal but includes an important safety feature: a toggle for “Enable tools that can edit your config.” This prevents accidental modifications to Burp’s configuration through AI interactions unless explicitly enabled. The extension also provides an automated installer specifically for Claude Desktop that handles extracting the proxy JAR to a known location and modifying the claude_desktop_config.json file.

For developers building similar integrations, the key insight here is the proxy pattern. When you need to connect systems with incompatible transports, a thin translation layer (like mcp-proxy-all.jar) can bridge the gap without forcing either side to compromise its architectural model. Burp remains a desktop app with a web server, Claude remains a stdio-based client, and the proxy handles the impedance mismatch. The extension’s build process uses Gradle with a custom embedProxyJar task that packages the proxy server directly into the extension JAR, ensuring users get a single artifact that contains everything needed for the stdio bridge.

Gotcha

The extension’s reliance on Java tooling creates setup friction for security professionals who aren’t Java developers. Both java and jar commands must be in your PATH (verified with java --version and jar --version), and you need to use the specific Java executable packaged with Burp for the Claude Desktop configuration. If you’re on a system with multiple Java versions or non-standard installations, troubleshooting path issues can be frustrating. The localhost HTTP server on port 9876 is another consideration. While the extension allows configuring the port through advanced options, users should be aware they’re running a local HTTP endpoint. Port conflicts with other local services would require manual resolution through the extension’s configuration UI. The extension is also currently optimized primarily for Claude Desktop—while the SSE server can work with other MCP clients by pointing directly to the server URL (either http://127.0.0.1:9876 or http://127.0.0.1:9876/sse depending on the client), the automated installer and documentation focus heavily on the Claude use case, meaning other integrations require more manual configuration work.

Verdict

Use if you’re a security professional already working with both Burp Suite and Claude Desktop, and you want to augment your security testing workflow with LLM capabilities. The automated Claude installer makes setup straightforward if you’re in this exact ecosystem, and the integration enables new workflows by connecting Burp Suite to AI clients through the Model Context Protocol. It’s particularly valuable for teams looking to leverage AI assistants in their security testing workflows based on real Burp data. Skip if you’re not already a Burp Suite user (this is purely an integration layer, not a standalone tool), or if you’re using MCP clients other than Claude Desktop where the setup requires more manual configuration. Also skip if you’re uncomfortable managing Java dependencies or running the Gradle build process. For teams building similar desktop-to-AI integrations, study this extension’s proxy architecture pattern—it’s a clean solution to the stdio transport problem that keeps both sides using their preferred transport mechanisms.