intruder-mcp
Official# Intruder MCP
Let MCP clients like Claude and Cursor control [Intruder](https://www.intruder.io/). For more information and sample use cases, please see [our blog post](https://www.intruder.io/blog/claude-intruder-mcp#intruder-mcp-use-cases).
## Installation
There are two ways to use the MCP server:
- Locally on your machine with Python
- In a Docker container
All of these methods require you to provide an Intruder API key. To generate a key, see [the documentation](https://developers.intruder.io/docs/creating-an-access-token).
### Running Locally
Install [uv](https://github.com/astral-sh/uv) if it isn't already present, and then clone this repository and run the following from the root directory:
```bash
uv venv
uv pip install -e .
```
Then, add the following to your MCP client configuration, making sure to fill in your API key, and update the path to where you have cloned this repository:
```json
{
"mcpServers": {
"intruder": {
"command": "uv",
"args": [
"--directory",
"path/to/intruder-mcp/intruder_mcp",
"run",
"server.py"
],
"env": {
"INTRUDER_API_KEY": "your-api-key"
}
}
}
}
```
### Running in a Container
Add the following to your MCP client configuration, making sure to fill in your API key:
```json
{
"mcpServers": {
"intruder": {
"command": "docker",
"args": [
"container",
"run",
"--interactive",
"--rm",
"--init",
"--env",
"INTRUDER_API_KEY=<your-api-key>",
"ghcr.io/intruder-io/intruder-mcp"
]
}
}
}
```
TDQS
Scored across 21 tools
Tools map cleanly to distinct resources and actions (scans, schedules, targets, tags, issues, occurrences), so misselection is unlikely. Minor overlap exists between get_scan/list_scans and list_occurrences/get_scanner_output, but the single-vs-list and output-vs-metadata distinctions are clear enough.
Every tool follows a strict verb_noun pattern (get_status, create_scan, list_targets, delete_scan_schedule, etc.) with no style mixing. The only trivial wrinkle is plural 'create_targets' vs singular tag tools, which does not impede predictability.
21 tools is on the heavier side but justified by a genuinely broad domain spanning scans, schedules, targets, tags, issues, occurrences, licenses, and user context. Each tool corresponds to a distinct operation, though a few (get_status, get_user) are minor conveniences.
Core lifecycle coverage is strong: schedules have full CRUD, scans support create/list/get/cancel, and targets/issues/occurrences support the main workflow operations. Gaps like no single get_target, no get_issue detail, and no update_target are minor and workable around.