Loading ToolBench
An MCP server for analyzing logs using AI, detecting anomalies, and providing system metrics through log ingestion, processing, and real-time analysis.
The AI Log Analyzer MCP defines 3 tools with basic structure but has significant definition quality gaps. Tool names are acceptably clear (verb_noun pattern: get_recent_logs, get_recent_anomalies, get_system_metrics), but descriptions are extremely brief (14-72 characters, well below the 194-char baseline for A+ tools). Input parameters lack descriptions entirely for the 'limit' parameter across 2 tools. Output schemas are not documented anywhere in the code. Error handling, security practices, and parameter validation are absent. The server uses FastMCP framework which does expose tool schemas, but the definitions themselves are skeletal. No pagination despite tools returning lists. No error recovery guidance. The codebase shows a working log analysis pipeline but the MCP interface does not meet production tooling standards.
Retrieve recent detected anomalies from storage
Retrieve recent logs from storage
Retrieve system metrics including log statistics and error rates
Parameter descriptions missing. 'limit' parameter in get_recent_logs and get_recent_anomalies has no description, LLMs cannot infer acceptable ranges or constraints. Parameter descriptions are required for ALL parameters per pattern:tool-description.
Tool descriptions are extremely brief (14 - 72 characters). 'Retrieve recent logs from storage' and 'Retrieve recent detected anomalies from storage' provide minimal context. Baseline for A+ tools is 194 chars; these lack guidance on when to call them, what they return, and dependencies on other tools. Per pattern:tool-description, descriptions should state WHAT, WHEN, and WHY.
Output schemas are not documented. None of the 3 tools declare what fields they return, what types those fields are, or what data structure to expect. LLMs cannot plan downstream tool calls without knowing the response schema. Per pattern:tool, 100% of A+ tools document return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
No pagination support. get_recent_logs and get_recent_anomalies accept a 'limit' parameter but provide no cursor, offset, or total_count in the response. Large result sets will blow context windows. Per pattern:paginated-result, tools returning lists must support pagination and return counts.
No error handling or recovery guidance. Tools have no documented error cases, no guidance for retries, and no actionable error messages. Per pattern:recovery-guide, errors must tell the LLM what to do next.
No parameter validation or constraints. 'limit' parameters have defaults (10, 5) but no min/max bounds declared. An LLM could pass limit=999999 or limit=-1 without guidance. Per pattern:constrained-input, numeric parameters need explicit ranges.
Parameter naming lacks type suffix. 'limit' is generic; 'limit_count' or a clear description would disambiguate. Per naming guidelines, numeric parameters should indicate unit/type.