Guides8 min read

Best MCP Servers for Security Engineers in 2026

AppSec, pentesting, vulnerability management, SIEM, and threat analysis — these MCP servers give security engineers AI assistance that understands the actual security stack.

By MyMCPTools Team·

Security engineering is one of the disciplines where AI assistance has the highest ceiling — and the most failure modes. An AI that doesn't understand your security stack gives dangerously confident wrong answers. An AI that does can dramatically accelerate vulnerability triage, policy writing, incident response, and code review.

These MCP servers give your AI assistant the security-specific context it needs to actually be useful.

1. Filesystem MCP Server — Code and Config Audit Access

Most security work starts with reading: reading application code for vulnerabilities, reading configuration files for misconfigurations, reading infrastructure-as-code for exposure. The filesystem MCP server gives your AI direct read access to your codebase — enabling genuine security analysis rather than pattern-matching on hypothetical examples.

Key capabilities:

  • Audit application code for injection vulnerabilities, hardcoded secrets, and insecure patterns
  • Review Terraform, CloudFormation, and Kubernetes manifests for misconfigurations
  • Inspect environment files and configuration for secret sprawl
  • Analyze dependency files for vulnerable package versions

Best for: Application security engineers doing code review and security assessment. Your AI can scan for OWASP Top 10 patterns across an entire codebase with real context about how the code actually works.

2. GitHub MCP Server — Vulnerability Triage and PR Review

The GitHub MCP server connects your AI to your repositories, issues, and pull requests — turning security-focused PR review into a collaborative workflow. Your AI can review incoming changes for security regressions, track vulnerability issues through to resolution, and search for vulnerable patterns across your entire organization's codebase.

Key capabilities:

  • Security-focused code review on pull requests
  • Vulnerability tracking through issues and milestones
  • Cross-repository code search for vulnerable patterns
  • Dependency version scanning across repositories

Best for: AppSec engineers embedded in development teams. Enables shift-left security by giving AI genuine PR review context rather than just scanning diffs in isolation.

3. Brave Search MCP Server — CVE Research and Threat Intelligence

Security engineers spend significant time researching CVEs, understanding threat actors, and following vulnerability disclosures. The Brave Search MCP server gives your AI access to current threat intelligence without hitting rate limits or requiring API key management for every search.

Key capabilities:

  • CVE detail lookup and impact analysis
  • Threat actor research and TTPs
  • Vulnerability disclosure timeline tracking
  • Security advisory monitoring

Best for: Security engineers who need current threat intelligence integrated into their analysis workflow. Ask "what's the latest on the Log4Shell exploitation patterns" and get real context rather than training data cutoff answers.

4. PostgreSQL MCP Server — Security Events and Audit Logs

Security data lives in databases: audit logs, access events, vulnerability scan results, asset inventories. The PostgreSQL MCP server gives your AI direct query access to your security database — enabling conversational analysis of security events that would otherwise require manual SQL writing.

Key capabilities:

  • Audit log querying and anomaly detection
  • Asset inventory analysis
  • Vulnerability scan result aggregation
  • Access control and permission analysis

Best for: Security operations teams with security data in PostgreSQL (common with tools like DefectDojo, Wazuh, and custom SIEM implementations). Ask your AI to "find all privileged access events from external IPs in the last 30 days" without writing the query yourself.

5. Docker MCP Server — Container Security Analysis

Container security requires understanding both the image layer composition and the runtime configuration. The Docker MCP server gives your AI visibility into your container environment — enabling analysis of image vulnerabilities, runtime security policies, and misconfigured containers.

Key capabilities:

  • Image inspection (layers, base images, installed packages)
  • Running container analysis (exposed ports, volume mounts, capabilities)
  • Docker Compose and Swarm configuration review
  • Network policy and container isolation analysis

Best for: Security engineers responsible for container security posture. Particularly useful for identifying containers running as root, overly permissive volume mounts, or containers with unnecessary capabilities.

6. Prometheus MCP Server — Security Metrics and Alerting

Security operations teams increasingly use Prometheus for security metrics: failed authentication counts, anomalous request rates, certificate expiry tracking. The Prometheus MCP server gives your AI access to these security signals through natural-language queries.

Key capabilities:

  • Security metric queries via PromQL
  • Alert rule review and gap analysis
  • Anomaly detection through metric analysis
  • Certificate and credential expiry monitoring

Best for: Security engineers who own the security monitoring stack. Ask "show me authentication failure spikes in the last week" and immediately correlate with incident timelines.

Recommended Stacks for Security Engineers

  • AppSec engineers: Filesystem + GitHub + Brave Search (code audit + PR review + CVE research)
  • Security operations: PostgreSQL + Prometheus + Brave Search (log analysis + metrics + threat intel)
  • Cloud security: Filesystem + GitHub + Docker (IaC review + container security)
  • Full security platform: All of the above — your AI understands the entire security lifecycle

Browse all Security MCP servers on MyMCPTools. For related guides, see MCP Server Security Best Practices and Best MCP Servers for DevOps.

Recommended Tools

Better Stack

Free Plan

Get alerted when your APIs, browser tests, payment pipelines, or MCP server dependencies go down. Used by 100K+ developers.

Start monitoring free →

1Password

14-day Free Trial

Store and inject API keys, payment credentials, tokens, and file access secrets into your MCP server configs. Trusted by 150K+ developers.

Try 1Password free →

🔧 MCP Servers Mentioned in This Article

📁

Filesystem MCP Server

sandboxed read, write, edit, move and search access to an explicit whitelist of local directories, and it is the reference implementation most other filesystem MCP servers are modelled on. Shipped by Anthropic in the official modelcontextprotocol/servers monorepo (89,000+ stars, actively maintained), it is a Node.js server published to npm as @modelcontextprotocol/server-filesystem. The part worth understanding before you install is the access-control model, because there are now two ways to grant directories and they do not compose. Method one is command-line arguments: `npx -y @modelcontextprotocol/server-filesystem /path/one /path/two`. Method two, and the one the maintainers recommend, is MCP Roots — a client that supports the roots protocol sends its roots at initialization, and those roots COMPLETELY REPLACE any directories passed on the command line, then get replaced again on every `notifications/roots/list_changed`. That means allowed directories can change at runtime without restarting the server, but it also means a roots-capable client silently overrides your CLI arguments. If the server starts with no arguments and the client either does not support roots or sends an empty list, initialization throws an error. The tool surface is broad: `read_text_file` (with mutually exclusive `head`/`tail` line windows), `read_media_file` returning base64 image/audio content blocks, `read_multiple_files` which keeps going when individual reads fail, `write_file`, `edit_file`, `create_directory`, `list_directory`, `list_directory_with_sizes`, `move_file`, `search_files`, `directory_tree`, `get_file_info` and `list_allowed_directories`. `edit_file` is the one to learn — it does line-based and multi-line pattern matching with indentation detection and preservation, returns a git-style diff with context, and supports `dryRun: true` so you can preview a change before applying it; the maintainers recommend always running a dry run first. Every operation is refused outside the allowed set, and `list_allowed_directories` is the fastest way to confirm what the server actually believes it can touch.

Local
💻

GitHub MCP Server

authenticated access to the whole GitHub platform — repositories, files, branches, issues, pull requests, Actions runs, security alerts, discussions and notifications — from Claude, Cursor, VS Code, Copilot CLI and any other MCP host. There is no npm package for this server, and that trips up most people who try to install it: `@github/mcp-server` is not published to the npm registry, so any `npx` line you find for it will fail. GitHub ships it three other ways. The easiest is the hosted remote server at https://api.githubcopilot.com/mcp/, which needs no install at all — point an HTTP-transport MCP client at that URL and log in with OAuth (VS Code 1.101+, Claude Desktop, Claude Code, Cursor and Windsurf all support this). The second is the official Docker image ghcr.io/github/github-mcp-server, which is what the copy-paste command on this page runs; on github.com it now performs a browser-based OAuth login on first use and keeps the token in memory only, which is why the published Docker configs map a fixed loopback callback port (-p 127.0.0.1:8085:8085 with GITHUB_OAUTH_CALLBACK_PORT=8085) so the container can receive the callback. Prefer a token? Set GITHUB_PERSONAL_ACCESS_TOKEN instead — it takes precedence over OAuth, and the minimum useful scopes are repo, read:org and read:packages. The third is the native Go binary from the repository's releases, which needs no fixed port for the OAuth flow. GitHub Enterprise Server has no hosted option: use the local server with --gh-host or GITHUB_HOST set to your instance (include the https:// scheme — it defaults to http://, which GHES rejects). Toolsets can be narrowed with GITHUB_TOOLSETS, and an insiders channel is available at /mcp/insiders or via the X-MCP-Insiders header.

Auth required📘
🔍

Brave Search MCP Server

The Brave Search MCP Server is the official server from Brave that gives AI assistants privacy-first web search through the independent Brave Search API — no tracking, no profiling, and results drawn from Brave's own web index rather than Google or Bing. It exposes five distinct tools that map directly to the Brave Search API endpoints: brave_web_search for general queries with pagination, freshness filters, and safe-search controls; brave_local_search for businesses, restaurants, and points of interest with automatic location filtering; brave_news_search for recent articles and current events; brave_image_search for image discovery; and brave_video_search for finding videos across the web. Authentication uses a single BRAVE_API_KEY (free tier available at brave.com/search/api) or a mounted BRAVE_API_KEY_FILE for Docker-secret setups. Install in Claude Desktop, Cursor, Windsurf, or VS Code with one npx command and choose stdio or streamable-HTTP transport. Because Brave operates its own crawler and index, the Brave Search MCP server is a strong choice for developers who want an alternative to Google-dependent search tools, need reproducible non-personalized results, or care about data privacy in agent workflows — Claude can pull fresh web context, verify facts, and research topics without leaking queries to ad-tech pipelines.

Local
🔧

Docker MCP Server

The Docker MCP server (ckreiling/mcp-server-docker) gives an AI assistant direct control of a Docker daemon over the Model Context Protocol: containers, images, networks and volumes, as tools rather than shell commands. It is the community server most people mean by "Docker MCP" — distinct from Docker’s own Docker MCP Gateway, which does not manage your containers at all but runs *other* MCP servers inside containers. If you want to ask Claude why the postgres container keeps restarting, you want this one; if you want a single secure endpoint in front of twenty catalog servers, you want the gateway. The tool surface is explicit and small enough to reason about: list_containers, create_container, run_container, recreate_container, start_container, fetch_container_logs, stop_container and remove_container for containers; list_images, pull_image, push_image, build_image and remove_image for images; list_networks / create_network / remove_network and list_volumes / create_volume / remove_volume for the rest. Two resource templates, docker://containers/{id}/logs and docker://containers/{id}/stats, let a client read logs and live stats by container ID or name without a tool call. It also ships a docker_compose prompt that puts the model into a plan-then-apply loop — you describe the containers you want under a project name, the model proposes a concise plan, and nothing runs until you approve it; reopening the prompt with the same project name re-reads the state of everything created under it, which is how you clean up after a lost chat. It runs on the Python Docker SDK’s from_env, so DOCKER_HOST applies: set ssh://user@host and the same server administers a remote engine. Two limits are deliberate and stated by the project — privileged options like --privileged and --cap-add/--cap-drop are not supported, and container configuration passes through the model, so no secrets belong in it.

Local📘
🔧

Prometheus MCP Server

The Prometheus MCP Server lets an AI assistant drive a live Prometheus instance through the HTTP API instead of you hand-writing PromQL in the expression browser — ask it why queries got slow, what is currently firing, or which recording rules would make an SLO cheap to evaluate, and it composes and runs the queries itself. One point of provenance worth knowing before you install: this began life as tjhop/prometheus-mcp-server and was adopted into the Prometheus organisation, so that path now 301-redirects to prometheus/prometheus-mcp, while release binaries and container images are still published under the tjhop namespace. The tool surface goes far past a single query endpoint. Instant and range queries (query, range_query, exemplar_query) sit alongside discovery tools — label_names, label_values, metric_metadata, list_targets, alertmanagers — and operational ones: list_alerts, list_rules, config, flags, build_info, healthy, ready, plus TSDB admin endpoints such as clean_tombstones, delete_series, snapshot, reload, wal_replay_status and quit. It also embeds the official prometheus/docs corpus as both tools (docs_list, docs_read, docs_search) and MCP resources under prometheus://docs, so the model can cite metric-naming best practice rather than invent it. Two features exist specifically to keep long investigations inside a context window: optional TOON (Token-Oriented Object Notation) encoding of API responses in place of JSON, and a configurable response-truncation limit that capable models can override per tool call. Prometheus-compatible backends are handled explicitly rather than assumed — a --prometheus.backend flag selects an implementation, and the Thanos profile removes the tools Thanos returns 404 for (config, alertmanagers, quit, reload, the TSDB admin set) while adding list_stores. Install as a Go binary from the releases page, as a Debian/RPM system package with a bundled systemd unit, via the OCI Helm chart at oci://ghcr.io/tjhop/charts/prometheus-mcp-server, or as a container: `docker run --rm -i ghcr.io/tjhop/prometheus-mcp-server:latest --prometheus.url "https://your-prometheus:9090"` for stdio, or add `--mcp.transport http --web.listen-address ":8080"` for streamable HTTP. Every flag has a PROMETHEUS_MCP_SERVER_* environment-variable equivalent. Secured Prometheus instances are reached with a standard Prometheus http_config file via --http.config, and the MCP endpoint itself can be put behind TLS and basic auth with a Prometheus web-configuration file via --web.config.file. Read the credential-forwarding note before exposing it: over HTTP transport the server forwards each request's Authorization header to Prometheus verbatim without validating it, requests without one fall back to the default client's credentials, and basic_auth_users in the web config conflicts with that forwarding — so anyone who can reach the endpoint can query Prometheus as at least the default client.

Local

📚 More from the Blog