Integration server for Wazuh SIEM with custom scripts for threat intelligence, active response, and external service integrations (MISP, VirusTotal, Telegram, OPNsense)
This server has severe definition quality issues. Tool names lack action verbs (e.g., 'opnsense-block' instead of 'block_ip', 'custom-telegram' instead of 'send_telegram_alert'). Descriptions are present but generic and lack context on WHEN to use each tool or what happens on failure. Input schemas are visible but incomplete: parameters lack type constraints, enums, and validation guidance. No output schemas documented. Error handling is absent, tools fail silently or with raw exceptions. Security-critical: API keys and secrets are exposed as parameters (misp_url, api_key, apikey in multiple tools), violating secret-injection pattern. No permission gates on destructive tools (remove-threat, opnsense-block). Tool composition is poor: request_misp_info and request_hash_from_api overlap; no clear separation of concerns.
Send Wazuh alerts to Telegram with formatted messages, supporting MikroTik-specific and generic alert modes
Extract attacker IP from Wazuh alert and add it to OPNsense firewall alias for blocking
Push file hash sightings to MISP server to record detection events
Send a request to VirusTotal API and fetch information about file hashes
Active response script to remove malicious files identified by VirusTotal integration
Search for a list of IoCs in MISP using the restSearch API
API keys and secrets exposed as tool parameters (misp_url, api_key, apikey in request_hash_from_api, push_misp_sighting, request_misp_info, query_api, request_virustotal_info). Secrets in parameters are logged in traces and prompt history, creating credential leakage risk.
Tool names lack action verbs and are inconsistent. 'opnsense-block' should be 'block_ip_in_firewall'; 'custom-telegram' should be 'send_telegram_alert'; 'remove-threat' should be 'delete_malicious_file'. Inconsistent naming (hyphens vs underscores) confuses LLM tool selection.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. E.g., request_misp_info returns JSON but structure is undocumented, agent cannot know if it includes syscheck.path for active response.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | <=2025-11-25 | v2 |
Extract IoCs from Wazuh alert and request information from MISP, supporting file hashes, registry keys, domains, and processes
Generate JSON message with VirusTotal enrichment data for file hash alerts
Destructive tools (remove-threat, opnsense-block) lack permission gates, confirmation steps, and error recovery guidance. No dry-run support. An agent could delete files or block IPs without authorization checks or user confirmation.
Parameter descriptions are generic and lack constraints. E.g., 'JSON-formatted log from Wazuh' does not specify required fields, format, or validation rules. No enums, regex patterns, or min/max bounds. LLMs cannot validate input before calling.