Loading ToolBench
MCP server for Security Onion that provides tools for querying events, retrieving playbook questions, and interacting with the Security Onion API
Security Onion MCP has 3 tools with varying quality. All tools have descriptions and are properly named with action verbs (ping, query_events, get_playbook_questions), but parameter descriptions are inconsistent and output schemas are not documented. The query_events tool has comprehensive parameter definitions with types, but lacks return type documentation. The ping tool is trivial (empty input schema). Error handling exists in implementation but is not surfaced in tool definitions. The server lacks tool annotations (readOnlyHint, destructiveHint) which should be present for security-conscious tools. No prompts, resources, or advanced MCP features are implemented.
Get playbook questions for a given alert/detection to guide investigation. When an alert is triggered, playbooks provide guided questions to help investigate the incident. This tool retrieves the playbook questions without executing queries, allowing you to build appropriate queries based on the questions and available data.
Simple tool to check if the server is running.
Executes a specific OQL query against the Security Onion event dataset.
No output schemas documented for any tool. Callers cannot plan downstream operations or extract required fields. query_events and get_playbook_questions both return complex structures with no type hints.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). All three tools are READ_ONLY but this is not declared in the MCP tool definition, only in metadata. LLMs cannot see the Risk field.
Parameter documentation uses example values instead of formal constraints. query_events start_time/end_time show examples 'e.g. -1h, 2023-10-26 10:00:00', LLMs may reuse these literally. Should use a regex pattern or enum.
query_events 'groupby_field' parameter is OQL-specific jargon with no guidance on valid field names. Parameter description doesn't explain what fields are available or how to discover them. No reference to a schema or discovery tool.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
get_playbook_questions 'alert_id' accepts two ID formats (event.id or rule.uuid) but doesn't guide LLMs on which to use or how they differ. Ambiguous parameter forcing guesswork.
No error guidance. Implementation catches exceptions and returns generic error dicts, but tool definitions don't describe error scenarios or recovery steps. LLMs won't know if errors are retryable or user-fixable.
No pagination or result limiting guidance. query_events accepts a 'limit' parameter (default 100) but description doesn't warn about context window impact or offer pagination cursors for large result sets.