Single tool 'loki_query' has a complete input schema with 8 parameters, all typed and described. Tool description is adequate (58 chars) but minimal. Parameter descriptions are present and reasonably detailed (e.g., 'LogQL query string', 'Loki server URL (default: http://localhost:3100 from LOKI_URL env var)'). However, output schema is not documented, the tool returns unstructured log results but the response format is not formally specified. No error handling guidance provided. Tool naming follows verb_noun pattern (loki_query) but is somewhat generic; 'query_loki_logs' would be more action-oriented. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present despite being READ_ONLY. Missing guidance on when to use this tool vs. alternatives, and no pagination/limit enforcement documented in the description.
Run a query against Grafana Loki
Output schema not documented. Tool returns log results but response structure (fields, types, pagination) is not formally specified. LLMs cannot plan downstream operations or extract structured data reliably.
Tool description lacks context on WHEN to use it and what it returns. Current description (58 chars) is below the 10 - 1024 char guideline sweet spot (194 chars median). Should explain: 'Query Grafana Loki for logs matching a LogQL expression. Returns matching log entries with timestamps and labels. Use this to search logs by job, service, or custom label filters.'
No error handling guidance. If Loki is unreachable, authentication fails, or query is invalid, the tool should return actionable recovery hints (e.g., 'Loki server unreachable at http://localhost:3100. Check LOKI_URL env var and network connectivity.'). Currently no such guidance visible.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
No tool annotations despite READ_ONLY risk classification. Tool should include readOnlyHint=true in its definition so agents know this is safe to retry and has no side effects.
Credentials exposed as optional parameters (username, password, token). Best practice is server-side secret injection via environment variables only. Current design allows credentials to leak into agent logs and prompt history if passed as parameters.