MCP ZAP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZAP_URL_WHITELIST | Yes | Comma-separated authorized target hostnames, for example app.example.com,api.example.com. Enter hostnames without https://, paths, or ports. Targets must be reachable from this cloud deployment. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| zap_scan_history_listA | List recent scan history and release-evidence entries, including queued scans, direct scan starts, and generated report artifacts. |
| zap_findings_summaryA | Get the first-pass findings view after a scan or passive-scan wait. This returns a concise grouped risk summary for fast triage. Use baseUrl to scope results to a specific host or path. |
| zap_attack_statusA | Get status for a guided active-scan operation. |
| zap_auth_session_prepareB | Prepare a guided auth session from an operator-managed profile. The requested target must remain on the profile's authorized origin. |
| zap_scan_history_release_evidenceB | Export a release or pilot handoff evidence bundle with summary counts, target coverage, warnings, and bounded ledger entries. |
| zap_attack_startA | Start a guided active scan for a specific target host or base URL after crawl/import setup. The server decides direct versus queued execution from deployment topology. When authSessionId is supplied, guided attack currently accepts prepared form-login sessions only. |
| zap_target_importC | Import an API definition into ZAP using one guided entrypoint for OpenAPI, GraphQL, or SOAP. |
| zap_report_readA | Read a generated report artifact back through MCP after zap_report_generate, without manual filesystem access. |
| zap_report_generateA | Generate a human-shareable report artifact using guided defaults. Use this after passive scan backlog drains when you want an export or handoff artifact; use findings summary/details for interactive triage. |
| zap_attack_stopA | Stop a guided active-scan operation. |
| zap_scan_history_getA | Read one scan history or release-evidence entry by ID. |
| zap_passive_scan_statusB | Get passive scan backlog and completion status. |
| zap_crawl_stopB | Stop a guided crawl operation. |
| zap_auth_session_validateA | Validate a prepared guided auth session before authenticated crawl or attack flows. |
| zap_crawl_startA | Start a guided crawl for a target host or root URL. The server decides direct versus queued execution from deployment topology. Use strategy=http for traditional server-rendered sites, strategy=browser for SPAs, login-heavy flows, or JavaScript-driven apps, and strategy=auto when you want the service to pick the default crawl engine. When authSessionId is supplied, guided crawl currently supports prepared form-login sessions on the HTTP spider path only. |
| zap_passive_scan_waitA | Wait for the passive scan backlog to drain before reading findings or generating reports. |
| zap_scan_history_exportC | Export a bounded scan history ledger snapshot as JSON for release evidence or handoff. |
| zap_crawl_statusB | Get status for a guided crawl operation. |
| zap_scan_history_customer_handoffA | Generate a customer-safe Markdown handoff summary from scan history without raw internal IDs, backend references, workspace IDs, or metadata. |
| zap_findings_detailsA | Drill into findings after reading the summary. By default this returns grouped details for matching alerts. Set includeInstances=true when you need bounded raw alert occurrences with concrete URLs, params, evidence, or attack samples. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools have distinct purposes (crawl, attack, scan history, findings, reports, auth), but zap_scan_history_list, zap_scan_history_get, zap_scan_history_export, and zap_scan_history_customer_handoff all operate on scan history and could be confused without careful reading. The descriptions do clarify different output formats and purposes, so the overlap is manageable.
The tools consistently use a zap_ prefix followed by a domain area (crawl, attack, scan, report, auth, findings) and a verb (start, stop, status, wait, get, list, export). Minor deviations like zap_findings_summary vs zap_findings_details and zap_scan_history_customer_handoff vs zap_scan_history_export are still readable and follow the general pattern.
20 tools is on the higher end but appropriate for a security scanner MCP covering crawl, attack, passive scan, findings, reports, auth, and scan history. Each tool maps to a distinct operation in the ZAP workflow, though a few could potentially be consolidated.
The tool set covers the main ZAP workflow: import target, prepare/validate auth, crawl, attack, passive scan wait/status, findings summary/details, report generation/read, and scan history export/handoff. Minor gaps include no explicit tool for managing crawl/attack configurations beyond start/stop, and no direct alert management, but the core lifecycle is well covered.