Loading ToolBench
Model Context Protocol server for Logz.io log management platform
Three read-only tools with complete schemas and generally strong descriptions. Tool naming follows verb_noun conventions (search_logs, query_logs, get_log_stats). Descriptions are detailed and include examples, though they prioritize user guidance over LLM-optimized clarity. All three tools have complete input schemas with types and constraints. However, output schemas are not documented in the provided code, and descriptions, while comprehensive, exceed the LLM-optimal 50-200 char range (ranging 200-900+ chars). Parameter descriptions are thorough. No security issues detected (no credential parameters). Error handling structure exists but details are limited. Tool composition is clean with single responsibilities.
Retrieve log statistics and metrics
Execute advanced Lucene queries against Logz.io logs. Supports complex search syntax including field searches, boolean operators, wildcards, ranges, and more. Use this for precise log analysis and complex filtering requirements. 🎯 **LUCENE SYNTAX EXAMPLES:** • Field searches: level:ERROR, host:web*, service:api • Boolean logic: (ERROR OR WARN) AND service:api • Ranges: status_code:[400 TO 499], timestamp:[2024-01-01 TO 2024-01-31] • Wildcards: message:timeout*, k8s_pod_name:pod-name* • Exclusions: level:ERROR AND NOT k8s_namespace_name:monitoring 🏷️ **COMMON PATTERNS:** • App errors: "service:myapp AND level:ERROR" • HTTP errors: "status_code:[400 TO 599]" • Pod issues: "k8s_pod_name:*myapp* AND (ERROR OR WARN)" • Time-based: "level:ERROR AND timestamp:[now-1h TO now]" ⚡ **PERFORMANCE TIPS:** • Avoid leading wildcards (*term) • Use specific fields instead of full-text search • Combine with time ranges for faster queries 💡 **TIP:** For simple text searches, use search_logs instead.
Search through Logz.io logs with filters and time ranges. Use this tool to find specific log entries, debug issues, or analyze application behavior. 🎯 **EXAMPLES:** • Simple text: query="error database connection" • App-specific: query="myapp" • Time-sensitive: query="payment failed" + timeRange="1h" • Error focus: query="timeout" + severity="error" 🔍 **SEARCH PRECISION:** • Multi-word queries are automatically treated as exact phrases • "this-should-not-return-results" will match exactly, not individual words • Use quotes explicitly for complex phrases: "error AND warning" • Use individual words for broader matching 🏷️ **COMMON FIELDS:** k8s_namespace_name, k8s_pod_name, container_name, level, host, service, env_id 💡 **TIPS:** • Use timeRange="1h" for recent issues, "24h" for broader analysis • Add severity="error" to focus on critical problems • For complex filtering, use mcp_logzio_query_logs instead
Output schemas not documented. Tool definitions include input schemas but omit return value structure. LLMs cannot infer what fields to expect or how to chain tool results to downstream calls.
Tool descriptions are verbose (200-900+ chars, exceeding 1024-char upper bound for search_logs/query_logs). LLMs process shorter descriptions more efficiently (optimal 50-200 chars). Current descriptions prioritize human examples over LLM clarity, with multiple subsections (EXAMPLES, TIPS, PATTERNS) that waste tokens during tool selection reasoning.
get_log_stats description is minimal ('Retrieve log statistics and metrics'). Does not explain when to use it vs search_logs/query_logs, what data it returns, or what the 'groupBy' array expects. Fails to answer: What does it do? When should the LLM call it instead? What does it return?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 14 | - | v1 |
get_log_stats schema is underspecified. 'groupBy' is an array of strings with no description of what strings are valid (field names? enum?). Input schema lacks examples and constraints. No 'required' array defined, making it unclear whether from/to/groupBy are optional or mandatory.
No documentation of output structures for any tool. search_logs and query_logs return log entries but LLM cannot see the field schema (does it include 'timestamp', 'message', 'level', 'service'? Are they strings or objects?). get_log_stats returns statistics but structure is unknown (buckets? aggregates?). Prevents agents from reliably extracting and chaining results.
Tool descriptions include example values (e.g., 'k8s_namespace_name, k8s_pod_name') that LLMs may reuse literally in real calls. Recommendation: replace examples with formal constraints (enums for severity, ISO 8601 format for dates).