scan-local-target

Check readiness and run the requested local workflow

Use this skill before every new local MCP ZAP crawl or scan workflow, including the bundled demo. Work on the scanner's machine through the client the user requested. A successful installation or earlier scan is not proof of current readiness. This is an agent workflow; it does not intercept calls sent directly to a separately configured MCP server.

For a pure status-only request, call zap_passive_scan_status once through the requested client's selected scanner connection and stop. Do not add setup, preflight commands, recovery or another client's status call to that request.

Identify the installation and request

• Retain the exact authorized target, crawl strategy, requested operations and restrictions. Ask for a target or intended workflow when missing. An HTTP crawl and passive analysis do not authorize an active attack.
• Identify the existing scanner checkout, its private .env, and the requested client's scanner alias and endpoint. Reuse the selected installation; do not search for another working scanner as a fallback. If several installations or aliases conflict, stop and ask which one to use.
• Read docs/getting-started/SELF_SERVE_FIRST_RUN.md in that checkout. This skill supports its standard local Docker Compose installation. For a native package, remote engine or customized deployment, explain the difference and follow that deployment's documented readiness procedure. Do not apply Docker recovery to a different installation type.
• Preserve every client's settings, disabled states, tool restrictions and approvals. A scan request does not authorize configuration edits, key replacement, image updates, Docker context changes or starting containers. Do not print credentials, source .env as shell code or include secrets in command arguments.

Read-only preflight

1. From the selected scanner checkout, run ./bin/scanner-readiness.sh with a bounded command deadline. Docker requests have a 15-second timeout each; an overall command timeout also blocks the workflow. This check must precede any new crawl or scan tool call. It checks the current local Docker endpoint, Compose ownership, settings, container state and authenticated readiness using the doctor with its tool-call probe disabled. It does not create settings, pull images, start containers or scan a target. If the helper is unavailable, stop and explain that this checkout needs the readiness-capable release; do not download or replace it silently.
2. Continue only after the helper returns READY. A nonzero exit, timeout or missing result blocks the workflow. Explain the reported category and next step without exposing private logs or key values. Follow the recovery rules below instead of trying a scan to see whether it works.
3. Prove the current client's connection by calling zap_passive_scan_status once with {} through its selected scanner alias. A doctor response, tool list, terminal HTTP request, or status from another client is not this proof. Check that the native call returns successfully; completion or backlog values describe existing passive work and are not permission to start more.
4. If tools are absent, authentication fails or the client connection is stale, stop before any crawl or scan. Offer reconnection of this server, preserving settings and approvals. Codex may need a new session or app restart. In Cursor, use the selected server's Reload control under Customize → MCPs when available. In Claude Code inspect /mcp and use its reconnect action when offered, otherwise request a new local session. Do not restart the user's app automatically. After the identified connection fix, recheck preflight and make one new native status call; do not retry in a loop.