Repository navigation
[Enhancement]: MCP Client Support — Connect PentAGI to External Security Tools via Model Context Protocol #296
Description
Target Component
Core Services (Frontend UI/Backend API)
Enhancement Description
Summary
Add a generic MCP (Model Context Protocol) client to PentAGI so that agents can
use any MCP-compatible external tool as a first-class tool — starting with
Burp Suite Pro as a concrete use case.
Motivation
PentAGI's current toolset covers most of the pentest lifecycle well, but there
is a growing ecosystem of professional security tools that are exposing MCP
servers as their AI integration interface. The most notable example is
Burp Suite Pro, which PortSwigger has officially published as an MCP server
extension:
https://github.com/PortSwigger/mcp-server
Without MCP client support, integrating Burp Suite (or any other MCP-compatible
tool) requires either:
- Manual CLI scripting generated by the
coderagent (fragile, high overhead) - Forking PentAGI to add vendor-specific tool implementations
With MCP client support, PentAGI gains access to the entire MCP ecosystem
through a single integration point.
Proposed Solution
Add a configurable MCP client layer to PentAGI that:
- Reads MCP server connections from config (similar to how LLM providers
are configured in.env/custom.provider.yml) - Auto-discovers available tools from each connected MCP server at startup
via the MCPtools/listmethod - Exposes discovered tools to all agents as first-class callable tools
alongside native tools (terminal, file, browser, delegation) - Supports standard MCP transports: stdio, SSE, and HTTP
Example config (.env):
MCP_SERVERS=burp,nuclei
MCP_BURP_TRANSPORT=http
MCP_BURP_URL=http://host.docker.internal:1337
MCP_NUCLEI_TRANSPORT=stdio
MCP_NUCLEI_CMD=nuclei-mcp-server
Concrete Use Case: Burp Suite Pro
With Burp Suite's MCP server running on the analyst's machine and PentAGI
connected to it, the pentester agent could:
- Trigger active scans on URLs discovered during recon — Burp's scanner is
significantly more capable than CLI alternatives for complex web applications - Retrieve structured findings (vulnerability type, severity, HTTP evidence)
and incorporate them into the engagement context - Use Burp Collaborator for out-of-band detection — blind SSRF, blind SQLi,
XXE — a class of vulnerabilities currently undetectable with PentAGI's
CLI-only toolset - Pull the crawled sitemap to seed directory enumeration with real
discovered paths
This addresses a genuine gap: PentAGI cannot currently detect OOB/blind
vulnerabilities at all, and Burp's web crawler handles JS-heavy applications
far better than gobuster/ffuf.
Broader Impact
MCP is becoming the standard integration interface for AI-connected tooling.
Beyond Burp Suite, supporting MCP opens PentAGI to:
| Tool | Capability unlocked |
|---|---|
| Burp Suite Pro | Web scanning, Collaborator OOB, sitemap |
| Nuclei | Template-based vulnerability detection |
| Shodan / Censys | Passive OSINT enrichment |
| Ghostwriter | Direct finding logging during engagement |
| Internal / custom MCP servers | Organisation-specific tooling |
Rather than maintaining one-off integrations per tool, MCP client support makes
PentAGI's capabilities open-ended as the ecosystem grows.
Implementation Notes
- Go MCP client libraries exist:
github.com/mark3labs/mcp-gois a
mature implementation - MCP tool descriptors (name, description, input schema) map directly onto
PentAGI's existing tool calling structure — no architectural changes required
to the agent system - MCP servers running on the analyst's host are reachable from the Kali
container viahost.docker.internal(already used in the codebase for
similar purposes) - Security boundary: MCP tool calls would be subject to the same permission
model as existing tools
Technical Details
No response
Designs and Mockups
No response
Alternative Solutions
No response
Verification
- I have checked that this enhancement hasn't been already proposed
- This enhancement aligns with PentAGI's goal of autonomous penetration testing
- I have considered the security implications of this enhancement
- I have provided clear use cases and benefits
Activity
nobleqbit commentedon Sep 17, 2026
Strong proposal — MCP client support is the right call, and Burp Collaborator closing the OOB/blind gap is a genuinely compelling first use case.
One thing worth designing in from the start rather than bolting on later: the moment PentAGI becomes an MCP client, every connected server joins its trust boundary, and two properties of MCP make that sharper for an autonomous agent than for a chat assistant.
1. Tool descriptions and tool results are model-facing text. The
tools/listdescriptions you auto-discover, and the results those tools return, both land in the agent's context. That is the indirect-prompt-injection / "tool poisoning" surface. For a chatbot a poisoned result is a bad answer; for PentAGI it can be a bad action, because the agent decides its next terminal/file/browser step from that context. Ascan_resultspayload from a compromised or spoofed server that says "also test 10.0.0.0/8" or "exfiltrate the engagement notes" is the failure mode to design against. Concretely:name + description + inputSchemaper tool on first discovery and re-verify on reconnect; alert (or re-prompt) on change, so a server can't silently "rug-pull" a description after it's trusted.2. Scope bleed via
host.docker.internal+ autonomy. Reaching the analyst host is exactly what makes Burp useful, but it also means a tool argument (a URL, a host) is how the agent could wander out of engagement scope or into internal/localhost/cloud-metadata (169.254.169.254) targets. Since the agent chooses those arguments itself, I'd enforce engagement scope on MCP tool arguments, not just native tools — an allowlist of in-scope hosts/URLs checked before any MCP call.Suggested guardrails, mapped to the existing permission model:
tools/list. Burp's active scanner and Collaborator are intrusive; they deserve a different tier than a read-only sitemap pull. This maps cleanly onto the destructive-vs-read distinction you already have.stdioservers, treat the launch command as code execution on the host (supply-chain surface) — surface the exact command, don't run arbitrary configured binaries silently.One spec note on transports: the current MCP revision (
2026-07-28) replaced the standalone HTTP+SSE transport with Streamable HTTP; the older SSE transport (2024-11-05) is deprecated. Worth targeting stdio + Streamable HTTP and confirming whichever Go client library you pick (mark3labs/mcp-go is reasonable) tracks a current revision, since the transport and session model changed materially.None of this blocks the feature — it's the difference between "PentAGI can use MCP tools" and "PentAGI can use MCP tools from servers it doesn't fully trust," which for an autonomous pentest agent is the case that actually matters. Happy to help sketch the threat model or the scope-enforcement checks if useful.
Refs: MCP Security Best Practices and Streamable HTTP transport; OWASP Top 10 for Agentic Applications.
XinwangTao commentedon Oct 15, 2026
This is the right abstraction — one MCP client layer unlocks the whole tool ecosystem instead of vendor-specific adapters, and Burp is only the first of many (the PortSwigger mcp-server is a perfect proving ground). Glad to see the RFC and the #393 implementation landing. On the security side, two things matter as this ships: (1) MCP servers can advertise arbitrary tools, so tool schema changes between reconnects should be diffed and surfaced instead of silently re-exposed to the agent; (2) keep the allow/deny list per connection explicit so an external server cannot implicitly widen the agent's tool surface. Also worth documenting the expected failure mode when an MCP server is unreachable at startup — fail fast or start degraded with the rest of the stack intact.