Loading ToolBench
MCP server for generating and validating WAF (Web Application Firewall) and Smart Firewall rules using Wirefilter expressions. Integrates CVE vulnerability templates from multiple sources including Nuclei Open Source and ProjectDiscovery API.
The server defines 6 tools with full input schemas and clear descriptions, but has significant gaps in output schema documentation, error handling guidance, and composition. All tools are READ_ONLY security-wise, which is good. Tool names are action-verb based (fetch_, list_, validate_, test_, get_) which is appropriate. Descriptions range from 150-300 chars, meeting the 10-1024 char guideline. However, output schemas are not documented in the provided definitions, and error handling is minimal. The tools show good specialization (validate vs test, fetch from one vs all sources) but lack actionable error recovery guidance. Parameter descriptions are present and adequate, with rule_type enums properly specified on WAF tools.
Fetch CVE vulnerability template from ALL enabled sources. Useful for comparing data across different sources.
Retrieve a CVE Indexed vulnerability template from multiple sources (Nuclei Open Source, Nuclei Paid API). Returns detailed information for the exploit including metadata, severity, description, references, classification, and characteristic request patterns.
Fetch the authoritative field/function schema from the validator for either 'waf' (HTTP L7) or 'smart_firewall' (L3/L4+JA4) rule types. This is the single source of truth for what fields and functions are available in the Wirefilter scheme, ensuring expressions stay in sync with the validator.
List all registered CVE source plugins and their status.
Validate and match a Wirefilter expression against test data. If no test data is provided, uses mock data. Returns valid (boolean), matched (boolean), and optional error fields.
No output schema documentation. Tools define inputs clearly but do not document what fields/structure the response contains. LLMs cannot plan downstream tool chaining or data extraction without knowing response shape.
Minimal error handling guidance. Tool descriptions do not explain what errors can occur, how to interpret them, or what recovery steps the LLM should take. E.g., validate_waf_expression mentions it returns {valid, error_message} but does not document when validation fails or what error conditions exist.
list_cve_sources description is generic ('List all registered CVE source plugins and their status'). Does not explain when to call it, what 'status' means, or how the LLM should interpret the result.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 73 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Validate a Wirefilter rule expression. rule_type selects the scheme: 'waf' (HTTP L7 fields, default) or 'smart_firewall' (L3/L4 + JA4 fields; http.* fields are NOT available and will be rejected). Optionally test against custom test data. Returns a dictionary with valid (boolean) and error_message (string) when invalid.
CVE fetch tools lack chaining context. fetch_cve_vulnerability_template and fetch_cve_from_all_sources likely return different response structures, but the descriptions do not clarify which fields/IDs are needed for downstream operations (e.g., using fetched CVE data in WAF rule generation).
test_waf_expression accepts optional test_data but description does not explain what happens if test_data is omitted or malformed. Relying on 'uses mock data' is vague and does not guide the LLM.