Skip to main content
Glama
dtkmn

MCP ZAP Server

by dtkmn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

zap_crawl_start

Start a guided crawl of a target host or root URL, selecting auto, HTTP, client-side, or browser strategy to map web app content for security scanning.

Instructions

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, strategy=browser for the existing AJAX Spider, or strategy=auto for the default crawl engine. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
strategyNoOptional crawl strategy: auto for the default engine, http for traditional link discovery, client for Client Spider on JavaScript-driven apps, or browser for AJAX Spider.
targetUrlYesTarget host or root URL to crawl, for example https://app.example.com or https://app.example.com/admin
authSessionIdNoOptional session ID from zap_auth_session_prepare. Use a kind=browser profile with strategy=client, or a kind=form profile with http/auto. The browser strategy means AJAX Spider and rejects authSessionId.
idempotencyKeyNoOptional idempotency key used only when guided execution selects queued mode; ignored in direct mode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.14.0
    • changedInput schema / properties / authSessionId / description
      Previous value: -"Optional prepared auth session ID from zap_auth_session_prepare. Guided crawl currently accepts form-login sessions only and rejects browser strategy when auth is supplied."New value: +"Optional session ID from zap_auth_session_prepare. Use a kind=browser profile with strategy=client, or a kind=form profile with http/auto. The browser strategy means AJAX Spider and rejects authSessionId."
    • changedInput schema / properties / strategy / description
      Previous value: -"Optional crawl strategy. Use auto to prefer the default guided engine, http for traditional pages and simple link discovery, or browser for SPAs, authenticated flows, and JavaScript-heavy navigation."New value: +"Optional crawl strategy: auto for the default engine, http for traditional link discovery, client for Client Spider on JavaScript-driven apps, or browser for AJAX Spider."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does well: it discloses that the server chooses direct versus queued execution, lists add-on and headless Firefox prerequisites for Client Spider, and constrains which auth sessions work with which strategies. It omits failure modes, permissions, and how to monitor or stop the crawl, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then layers in server behavior, strategy mapping, prerequisites, and auth constraints. Every sentence earns its place and there is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-strategy crawl-start tool with rich schema coverage and no output schema, the description covers the key decision points an agent needs: when to choose each strategy and which auth sessions are compatible. It could go further by noting that execution may be asynchronous or by pointing to zap_crawl_status/zap_crawl_stop.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds practical meaning beyond the schema: it explains which strategy suits which site type, notes Client Spider add-on requirements, and maps auth-session kinds to strategies. It does not elaborate on targetUrl or idempotencyKey behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Start a guided crawl for a target host or root URL.' It is clearly distinct from attack or scan tools, but it never names a sibling to differentiate from, such as zap_attack_start, so it stops short of the top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit strategy-selection guidance for traditional sites, JavaScript apps, AJAX Spider, and the default engine, and adds auth-session compatibility rules. It does not state when to prefer this tool over sibling tools like zap_attack_start, but the strategy guidance is detailed and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools