Skip to main content
Glama
dtkmn

MCP ZAP Server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ZAP_URL_WHITELISTYesComma-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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": true
}
resources
{
  "subscribe": false,
  "listChanged": true
}
completions
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 21 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityActive
ResponsivenessWithin a week