OLB exposes 9 WAF management tools with basic schemas and descriptions. All tools have names starting with action verbs (waf_*) and descriptions present. However, critical gaps undermine production readiness: (1) Parameter descriptions are minimal or absent for several tools (e.g., waf_status has empty input {}); (2) Output schemas are not documented anywhere in the provided code, LLMs cannot predict what fields to expect; (3) No error handling guidance, tools return raw errors without recovery hints; (4) No pagination support despite tools like waf_get_top_blocked_ips and waf_get_attack_timeline returning lists; (5) Destructive operations (waf_add_whitelist, waf_add_blacklist) lack confirmation patterns or dry-run support. Tool names are clear and verb-prefixed, which is a strength. Descriptions average ~80 chars, meeting baseline minimums but lacking depth on WHEN to use each tool or what downstream actions they enable.

• Document output schemas for all tools. Example for waf_get_stats: {"total_requests": number, "blocked_requests": number, "monitored_requests": number, "detector_hits": {[detector_name]: number}}. This enables LLMs to chain tools and extract the right fields.
• Add actionable error messages. Replace 'Invalid CIDR' with 'Invalid CIDR format. Use 10.0.0.0/8 (CIDR) or 192.168.1.1 (single IP). Example: 10.0.0.0/8 blocks all IPs in that range.'
• Implement pagination for list tools. Add offset/limit to waf_list_rules and waf_get_attack_timeline. Return total_count and next_offset so agents can iterate without re-fetching.
• Add confirmation step for destructive operations. waf_add_whitelist and waf_add_blacklist should support a dry_run=true parameter that returns what would change without applying it.
• Expand parameter descriptions with context. For waf_list_rules 'type' param: 'Filter rules by type. Use "whitelist" to see IPs that bypass all checks, "blacklist" for IPs that are immediately blocked, "all" for both. Useful before modifying rules to avoid conflicts.'