Loading ToolBench
Google SecOps MCP server for Chronicle Security Operations
The server defines 5 tools for Chronicle security operations, all with READ_ONLY risk classification. Tool names follow verb-noun conventions (search_, get_, lookup_, list_) which is good. However, descriptions vary significantly in quality and detail. Most critically, while input schemas are present with type definitions, the output schemas are entirely undocumented, the code shows the tools are implemented but no return structures are specified for the LLM. Parameter descriptions are present but often generic. The server is functional but lacks the polish and completeness expected of production-grade tools.
Get Indicators of Compromise (IoC) matches from Chronicle.
Get security alerts from Chronicle.
List security rules from Chronicle.
Look up an entity (IP, domain, hash, etc.) in Chronicle.
Search for security events in Chronicle using natural language. This function allows you to search for events using everyday language instead of requiring UDM query syntax. The natural language query will be automatically translated into a Chronicle UDM query for execution. Examples of natural language queries: - "Show me network connections from yesterday for the domain google.com" - "Display connections to IP address 192.168.1.100"
Output schemas completely undocumented. No return structure is specified for any tool, making it impossible for LLMs to know what fields to expect or how to chain results to downstream operations. The example.py shows tools return JSON objects with 'total_events', 'events', 'total_alerts', etc., but none of this is declared in tool metadata.
Four of five tools have minimal descriptions (<50 characters). 'Get security alerts from Chronicle.' and 'Look up an entity (IP, domain, hash, etc.) in Chronicle.' provide almost no context about when to use each tool, what distinguishes them, or what they return. LLMs cannot differentiate between similar tools with such bare descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
Parameter descriptions are generic and lack actionable detail. For example, 'hours_back' appears in all tools but is never explained, what does 'look back' mean for a rules listing? Does it apply? The descriptions should clarify scope, default behavior, and interaction with other parameters.
No error handling guidance. The tools declare no error responses, recovery actions, or what to do if a lookup fails, a query returns no results, or permission is denied. LLMs have no guidance on whether to retry, ask the user, or assume the data doesn't exist.
No pagination support documented. 'get_security_alerts' defaults to 10 results, 'search_security_events' to 100, and 'get_ioc_matches' to 10. There is no indication of how LLMs can retrieve additional results or if these are hard caps. The tools should support limit, offset, or cursor parameters with clear pagination semantics.
No input validation rules documented. Parameters like 'project_id', 'customer_id', and 'hours_back' lack format, length, or range constraints. The 'hours_back' integer parameter has no stated minimum/maximum, inviting LLMs to pass invalid values (e.g., negative numbers, 999999).
Parameter 'text' in search_security_events conflates two use cases: natural language queries and UDM query syntax. The description mentions both but does not clearly explain which mode activates automatically, whether the system auto-detects, or how the user specifies intent. This ambiguity will cause LLM confusion.