Loading ToolBench
Autonomous Security Operations Center agent integrated with Elasticsearch/Elastic Security for alert investigation, evidence gathering, playbook retrieval, and automated response execution with confidence-gated escalation.
This MCP server has moderate definition quality with some strengths but significant gaps. All 9 tools have names starting with action verbs (search_, get_, query_, retrieve_, execute_, create_, update_, log_) which follows naming conventions. However, parameter descriptions are present but often lack critical constraint information, and output schemas are not documented. The execute_action tool is particularly concerning as a multi-responsibility tool that combines decision logic, dispatch, and logging. Error handling is present in the code but not surfaced in tool descriptions. Descriptions range from adequate (search_alerts: 120 chars) to minimal (get_asset_profile: 74 chars), clustering below the 194-char production baseline. No input schemas show explicit type definitions beyond what's inferred from the code, JSON Schema format is not visible in the provided source.
Create an Elastic Security case via the Cases API. Falls back to logging in soc_agent_log if Cases API unavailable.
Execute a response action. Confidence-gated: confidence >= 0.85 executes autonomously, 0.70-0.84 executes with warning logged, < 0.70 escalates to human without execution. All actions logged to soc_agent_log.
Get complete details for a specific alert by ID.
Look up user/host criticality, privilege level, and department from asset inventory.
Log execution step to soc_agent_log for audit trail and monitoring.
Run an Elasticsearch query against any index for investigation evidence. Returns hits and aggregations.
execute_action combines multiple responsibilities: decision gating by confidence, tool dispatch, logging, and escalation logic. This violates single-responsibility principle and makes composition difficult.
Output schemas are not documented for any tool. LLMs cannot predict what fields to extract from responses, forcing inference from code inspection or trial-and-error.
Parameter descriptions lack constraint details. E.g., 'severity' param says 'Filter by alert severity' but doesn't state that enum values (low|medium|high|critical) are the only valid inputs. 'limit' and 'top_k' have no min/max bounds documented in descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
Semantic kNN search to find the best matching playbook for an alert. Uses dense vector similarity — the core of the agentic retrieval system. Returns top matching playbooks with similarity scores.
Search Elastic Security alerts. Returns open alerts filtered by severity, sorted by risk score descending.
Update alert workflow status in Elastic Security (open/acknowledged/closed/in-progress).
query_evidence accepts arbitrary Elasticsearch Query DSL object, no validation shown in source. This is a prompt injection vector if an untrusted agent passes malicious DSL. Requires sanitization.
Error responses in code (e.g., get_alert_detail returning {'error': str(e)}) are minimal. They do not guide LLMs on recovery actions, which tools to try next, or whether the failure is retryable.
Descriptions for get_alert_detail (45 chars), get_asset_profile (74 chars), and update_alert_status (50 chars) are below the 100-char minimum for clarity. Too terse to serve as actionable LLM prompts.
No pagination or result limits documented in descriptions for search_alerts and retrieve_playbook, though code implements them. LLMs are unaware they can pass 'limit' to cap results.
Permission gating and role-based access control for sensitive tools (execute_action, create_case, update_alert_status) are not visible in definitions. No scope declarations (e.g., 'requires: write:alerts, read:assets').