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 | Read currently recorded alerts, including while scan work is in progress, as a concise grouped risk summary for fast triage. Alert counts do not establish scan completion, coverage, or safety. Requires a nonblank target baseUrl covered by scan evidence visible to the caller. |
| 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. Use a kind=browser profile for Client Spider, or kind=form for HTTP spider and active scans. 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_importA | Import an OpenAPI/Swagger definition, GraphQL schema, or SOAP WSDL to prepare API endpoints for testing. Use when you have an API definition; use zap_crawl_start to discover ordinary web pages. Requires a reachable, configured ZAP instance with the matching OpenAPI, GraphQL, or SOAP add-on. Import changes the current ZAP session and may send requests to the definition source and API targets; use only authorized targets. It does not start an active scan: after reviewing import messages, call zap_attack_start with the API target URL only when active testing is permitted and approved. Content mode accepts actual OpenAPI JSON/YAML text with a required full HTTP(S) hostOverride and an explicitly enabled shared filesystem; it cannot read chat attachments automatically. Returns plain text containing definition type, source kind, and import status. URL/file mode also includes source and engine messages; content mode withholds contents, internal paths, and raw engine warning text. Review warnings before proceeding. Invalid inputs, blocked URLs, and ZAP API failures raise errors. |
| zap_report_readA | Preview a generated report artifact through MCP after zap_report_generate. If truncated, use zap_report_read_chunk to retrieve the complete artifact in bounded pages. |
| 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_report_read_chunkA | Retrieve a generated UTF-8 report in bounded JSON pages. Append content in order, follow nextOffset until endOfFile=true, and supply the first page's artifactSha256 as expectedSha256 on later pages. Offsets and maxChars count Unicode code points. Artifacts are limited to 50 MiB; the SHA-256 identifies the full original UTF-8 file. |
| 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=client for JavaScript-driven apps using Client Spider, or strategy=browser for the existing AJAX Spider API. strategy=auto starts with HTTP Spider; only an unauthenticated direct HTTP start failure triggers AJAX fallback. Auto does not detect JavaScript coverage. Client Spider requires the Client Side Integration add-on and headless Firefox. Prepared browser authentication sessions require strategy=client; prepared HTTP form-login sessions require http or auto. |
| zap_passive_scan_waitA | Wait for the passive scan backlog to drain before reading findings or generating reports. |
| zap_scan_history_exportA | Export scan history as inline JSON text for internal evidence processing; no export file is created. Use zap_scan_history_list for a readable listing, zap_scan_history_release_evidence for a summary bundle, or zap_scan_history_customer_handoff for a customer-facing summary. Returns version, generatedAt, retentionDays, entryCount, and entries containing scan/job/artifact records, including internal IDs, paths, and metadata; review before sharing. Only records accessible to the caller in the current workspace are included, newest first. Omitted or blank filters select all accessible records; supplied filters combine with AND. The snapshot is capped by limit, has no pagination, and returns an empty entries array when nothing matches. It does not start scans or contact targets. Querying may delete expired stored ledger entries under the configured retention policy; it does not refresh scan outcomes from ZAP. |
| 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. Requires a nonblank target baseUrl covered by scan evidence visible to the caller. 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 21 tools
Crawl, attack, passive scan, auth, report, findings, and history operations are generally well separated by distinct resource+action names. The main overlap is within scan history (list/get/export/release_evidence/customer_handoff) and report_read vs report_read_chunk, but descriptions clarify their roles. A few boundary cases remain, such as choosing among history export variants, which adds mild confusion.
All tools consistently use the zap_ prefix followed by snake_case resource/action naming (e.g., zap_crawl_start, zap_attack_stop, zap_findings_summary). Verb and resource ordering is predictable throughout, with no mixed casing or style deviations.
At 21 tools, the count is on the heavy side but reasonable for a security scanning domain that must cover crawl, attack, auth, reports, findings, import, and history workflows. Each tool appears to serve a distinct lifecycle operation, though the history surface is somewhat expansive.
The surface covers the core lifecycle well: crawl/attack start-stop-status, passive scan wait/status, auth prepare/validate, target import, findings summary/details, report generation/reading, and history inspection/export. Minor gaps exist, such as no explicit alert disposition/false-positive management or session cleanup/configuration tools, but core workflows are covered.