Loading ToolBench
MCP server for ModSecurity WAF management — monitor, analyze, and configure OWASP CRS via AI assistants
Strong tool naming (verb_noun pattern, clear intent) and comprehensive descriptions (avg 150 chars, well above 10-char minimum). All 15 tools have explicit schemas with typed parameters and regex validation for IPs/rule IDs. Good parameter descriptions explaining constraints. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling is minimal; no recovery guidance or actionable error messages. Missing tool annotations (readOnlyHint/destructiveHint) despite clear read/write distinction. No pagination support on list-like tools (waf_top_ips, waf_top_rules, waf_events_by_ip). Composition is clean (single responsibility per tool), but some tools could batch operations.
Whitelist an IP address to bypass WAF inspection entirely.
Remove an IP address from the WAF whitelist.
Disable a specific ModSecurity rule by ID to suppress false positives.
Re-enable a previously disabled ModSecurity rule by ID.
Full deep-dive into a single event by index. Shows all request headers, body snippet, all rule matches with matched data, and response code.
Drill into events from a specific IP address. Shows timestamps, methods, URIs, HTTP codes, and triggered rules.
Drill into events that triggered a specific rule. Shows timestamps, IPs, methods, URIs, HTTP codes, and matched data.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. Forces agents to guess or fail mid-plan.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools clearly split into read (8) and write (5) categories, but LLMs cannot infer safety/idempotency without explicit hints.
List tools (waf_top_ips, waf_top_rules, waf_events_by_ip, waf_events_by_rule) lack pagination. Default count=10-20 is reasonable, but no offset/cursor or total_count returned. Large result sets could exhaust context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
Rules that triggered on HTTP 2xx responses — likely false positives. Critical for WAF tuning.
High-level WAF dashboard: total events, unique IPs, unique rules, events in last hour. Start here to assess if anything needs attention.
Change WAF engine mode: On (actively blocking), Off (disabled), or DetectionOnly (log without blocking).
Set CRS paranoia level (1-4). Level 1 is minimal rules, level 4 is maximum security with more false positives.
Get WAF container health, engine mode, rules loaded, and paranoia level.
Run the WAF test suite to verify blocking and pass-through rules are working correctly.
Top attacking IPs with hit counts, geo info, and last seen timestamp. Use to identify most active sources.
Most frequently triggered WAF rules with severity and description. Use to identify dominant attack patterns.
Error handling not visible in source. No recovery guidance, error classification, or actionable messages. If a tool fails, LLM has no guidance on retry vs user-fixable vs fatal.
Destructive operations (waf_disable_rule, waf_enable_rule, waf_allow_ip, waf_deny_ip, waf_set_engine) lack confirmation/dry-run pattern. Agents can accidentally disable critical rules or whitelist attackers.