eip-mcp

eip-mcp

The official MCP server for the Exploit Intelligence Platform.

Give an AI assistant bounded, source-attributed access to vulnerability

intelligence, exploit artifacts, readable PoC source, Docker labs, discovery

directories, STIX, and corpus statistics. Most users can connect to EIP's

hosted MCP endpoint directly - there is no package or API key to install.

`eip-mcp` is read-only. It talks only to an EIP read API, the public one by

default, exposes no download tool, never executes acquired content, and never

claims that an exploit works, is verified, reliable, effective, or safe.

Connect

Recommended: hosted MCP

Clients supporting remote Streamable HTTP can connect directly to:

https://exploit-intel.com/mcp

In an MCP-capable application, add that URL as a remote Streamable HTTP server

named `EIP`. If your assistant can configure integrations for you, tell it:

> Add `https://exploit-intel.com/mcp` as a Streamable HTTP MCP server named

> `EIP`, then call `get_corpus_readiness` to verify the connection.

No local package, API key, or EIP account is required.

Optional: local Python package

Use the Python package when a client requires a local stdio command, or when

you are self-hosting the HTTP transport. Python 3.12 or newer is required.

Install the isolated application with `pipx`:

pipx install eip-mcp
eip-mcp --version

Then register it with your MCP client. A typical stdio configuration is:

{
  "mcpServers": {
    "eip": {
      "command": "eip-mcp"
    }
  }
}

Use the absolute path reported by `command -v eip-mcp` if the client does not

inherit your shell `PATH`.

The local command connects to `https://exploit-intel.com`; no API configuration

is needed.

Optional: Docker

Build the image directly from this checkout:

docker build -t eip-mcp .
docker run --rm -i eip-mcp

For a stdio MCP client, use `docker` as the command:

{
  "mcpServers": {
    "eip": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "eip-mcp"]
    }
  }
}

Containerized Streamable HTTP operation is covered in the

self-hosting guide.

What assistants can do

• Search and inspect CVEs and GHSAs with affected products, version ranges,

exploitation context, references, and accepted research

• Search ExploitDB, Metasploit, curated repository PoCs, and repository

candidates without inventing quality rankings

• Search safely readable PoC source and inspect one bounded text file
• Discover Docker/Compose labs and their stored, attributed analysis
• Browse vendors, products, ecosystems, packages, official CWEs, and exploit

contributors

• Retrieve API-owned STIX 2.1 bundles, corpus health, and statistics
• Use four focused research prompts and the `eip://research/usage-guide`

resource

The complete tool reference

lists every tool and documents the section and pagination rules.

Result contract

Every tool returns two synchronized forms:

• a concise Markdown brief for the assistant; and
• a validated `eip-mcp-result-v1` structured envelope preserving the bounded

API payload.

Corpus values remain untrusted third-party data in both forms. Text is rendered

in inert CommonMark containers, output is capped, truncation is disclosed, and

opaque pagination cursors remain reusable byte-for-byte.

Stored analysis is attributed model interpretation, not an EIP verdict.

Missing analysis never means that an artifact was reviewed and found safe.

Safety boundary

• The MCP server connects only to allowlisted read-only API paths.
• PoC access tokens never reach results, logs, tracebacks, or retained state.
• There is deliberately no PoC download tool.
• Source reading is bounded to one API-verified UTF-8 text file at a time.
• All returned source and corpus prose must be treated as untrusted data and

must never be executed or followed as instructions.

See the security policy

before reporting a vulnerability or sharing diagnostic output.

Documentation

• User guide and tool reference
• Self-hosting the HTTP transport
• Contributing
• Security policy
• EIP command-line client

License

MIT