Loading ToolBench
A powerful Model Context Protocol (MCP) Server that integrates OWASP ZAP with AI assistants for security scanning and vulnerability detection
The server provides 4 well-defined security scanning tools with complete JSON schemas and reasonable descriptions. All tools have proper input parameter definitions with types, defaults, and descriptions. However, descriptions are functional but generic, they explain WHAT the tool does but lack WHEN to use it or key prerequisites. Notably absent: tool annotations (readOnlyHint, destructiveHint, idempotentHint), output schema documentation, and error handling guidance. The tools follow a clear verb_noun pattern and have non-overlapping responsibilities, meeting composition standards. Parameter naming is consistent and descriptive. The main deficit is description depth (most are 80 - 150 chars, below the 194-char baseline for A+ tools) and lack of error recovery guidance. This is solid B-range work, production-ready schemas with room for LLM optimization.
Run an active security scan using OWASP ZAP's active scanning engine
Run an AJAX crawling scan to discover JavaScript-rendered content
Run a complete security scan combining AJAX crawling, spidering, and active scanning
Run a passive security scan that analyzes traffic without sending active probes
Descriptions lack WHEN-to-use guidance and prerequisites. E.g., 'Run an active security scan' does not explain when to choose active_scan vs passive_scan vs complete_scan, or what prerequisites (target must be in scope, ZAP instance must be running) are required.
No tool annotations present. Tools should declare readOnlyHint=true (security scanning is non-destructive) and idempotentHint=true (repeated calls with same parameters yield same results). This enables agents to optimize retry logic and request batching.
Output schemas are not documented. Callers cannot plan downstream operations. What fields does active_scan return? Are there vulnerability details, a scan ID for status polling, or summary counts? Without documented return types, LLMs cannot chain operations or extract key data.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | 2024-11-05+ | v1 |
No error handling guidance in tool descriptions. Scans can timeout, fail due to unreachable targets, or encounter permission errors. Descriptions should indicate: (1) which errors are retryable, (2) what the agent should do if the target is unreachable, (3) how to interpret partial results.
Parameter descriptions are minimal and lack constraints. E.g., 'poll_interval_seconds' has no stated range (should be 0.5 - 60?). 'spider_max_wait_seconds' defaults to 1800 but no min/max stated. 'scanPolicyName' has no enum of valid policy names, forcing LLMs to guess or call a discovery tool.
Descriptions are 65 - 95 characters, well below the 194-char baseline for A+ tools. E.g., 'Run a passive security scan that analyzes traffic without sending active probes' is functional but lacks depth: What does 'passive' imply for coverage? When would an agent prefer this over active? What's the typical runtime? These details would help LLMs choose the right tool.