Loading ToolBench
Model Context Protocol server for FortiAnalyzer JSON RPC API
The FortiAnalyzer MCP server demonstrates solid fundamentals with consistently well-named tools (verb_noun convention: list_, get_, create_, delete_, add_, acknowledge_, run_, fetch_), comprehensive parameter descriptions, and explicit input schemas across all 16 tools. Tool annotations are properly declared for risk classification (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). However, several issues prevent a higher score: (1) Output schemas are completely undocumented, no tool documents what fields it returns, breaking the pattern:tool-chain requirement that downstream tools know what to expect; (2) Parameter descriptions lack crucial details like valid ranges, enums, and formatting constraints, e.g., 'time_range' accepts multiple formats ('1-hour', '6-hour', custom 'start|end') but no validation is visible; (3) Error handling is silent, no evidence of actionable recovery guidance or categorization; (4) Some parameter dependencies are implicit (e.g., 'ip' vs 'serial_number' in add_device are mutually exclusive but not stated); (5) No pagination metadata is visible in list tools (get_alerts, get_incidents have limit/offset but no documented total_count or has_more response); (6) Tool compositions risk chain breakage, e.g., run_fortiview returns a TID but there's no guarantee fetch_fortiview documents what it expects.
Acknowledge one or more alerts. Marks alerts as acknowledged for SOC workflow tracking.
Add a new device to FortiAnalyzer. Registers a device with FortiAnalyzer for log collection. Can add either a real device (with IP) or a model device (with SN).
Add multiple devices to FortiAnalyzer in bulk. Registers multiple devices at once for efficiency.
Create a new security incident. Creates a manual incident for SOC tracking and investigation.
Delete a device from FortiAnalyzer. Removes a device registration. Does not affect the actual device. WARNING: This operation cannot be undone.
Fetch FortiView query results by TID. Retrieves results from a previously started FortiView query.
No output schemas documented for any tool. Users and downstream tools cannot determine what fields to expect from responses, breaking tool chaining and forcing wasteful discovery calls.
Parameter constraints missing. 'time_range' accepts multiple formats ('1-hour', '6-hour', '12-hour', '24-hour', '1-day', '7-day', '30-day', or custom 'start|end') but no enum or pattern is visible. LLMs will hallucinate invalid formats like '2-day' or '45-min'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 23 | - | v1 |
Get count of alerts matching criteria.
Get log entries associated with alerts. Retrieves the original log events that triggered the alerts.
Get alert events from FortiAnalyzer. Retrieves security alerts generated by event handlers and correlation rules.
Get a specific incident by ID. Retrieves detailed information about a single incident.
Get count of incidents matching criteria.
Get security incidents from FortiAnalyzer. Retrieves incidents from the incident management module. Incidents can be created manually or automatically from alerts.
List all device groups in an ADOM. Device groups allow organizing devices for policy and log management.
List VDOMs for a specific device. Virtual Domains (VDOMs) are independent virtual instances within a FortiGate device.
Start a FortiView analytics query. FortiView provides real-time visibility and analytics dashboards. This starts an async query and returns a TID for fetching results.
Unacknowledge one or more alerts. Removes acknowledgment status from alerts.
Undocumented parameter dependencies. In add_device, 'ip' and 'serial_number' appear mutually exclusive (one for real device, one for model device), but descriptions do not state this. LLMs may pass both or neither.
Pagination metadata missing. list_device_groups, list_device_vdoms, get_alerts, get_incidents all accept limit/offset but no documentation of total_count, has_more, or cursor response fields. Agents cannot reliably iterate.
No error handling documentation. No evidence of actionable error messages, categorization (retryable vs fatal), or recovery guidance. Agents will not know what to do on failure.
Destructive operations (delete_device) lack confirmation/dry-run support. Pattern:confirmation-request recommends a preview step to prevent accidental deletion.
Tool chaining risk: run_fortiview returns a TID, and fetch_fortiview consumes it, but no documentation ensures the response field name matches the expected parameter name. Broken references force discovery calls.
add_device and add_devices_bulk both expose 'admin_pass' (password) as a parameter. Passwords in parameters are logged and appear in traces. Credentials should use server-side secret injection.
Parameter descriptions lack format guidance. 'device' (in list_device_vdoms), is this the display name or serial number? 'view_name' in run_fortiview, are hyphens required or underscores? No regex patterns or examples.