Loading ToolBench
Real-time log capture MCP server for development projects with remote process control
The server has 9 well-defined tools with explicit schemas and descriptions visible in mcp-logs/src/mcp/tools.ts. Naming follows verb_noun convention consistently (get_*, search_*, list_*, clear_*, restart_*). Descriptions are present and moderately detailed (range 70-250 chars, within 10-1024 baseline). Most tools have type-safe parameter schemas with enums where appropriate. However, several issues prevent a higher score: (1) output schemas are not documented anywhere in the code provided, tool descriptions tell what they do but not what fields are returned, which forces LLMs to guess at response structure; (2) some parameter descriptions lack constraint detail (e.g., 'count' in get_recent_logs says 'max: 500' but doesn't enforce validation messaging); (3) error handling and recovery guidance are not evident in tool definitions; (4) no tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present, though risk classification is provided in the evaluation context; (5) clear_logs and restart_process are high-risk operations lacking confirmation or dry-run patterns. Tools are well-composed and avoid overlapping responsibilities. Parameter naming is consistent (project, limit, query patterns repeat logically).
Clear all logs from memory. Use with caution!
Get advanced analytics and aggregations on logs. Provides insights like error rates, trends over time, top messages, and more. Perfect for understanding patterns and detecting issues.
Get all error-level logs. Useful for debugging and finding issues.
Get logs with advanced filtering options. Search by project, level, source, time range, or text content. Supports relative time formats like 'last 1h', 'last 30m', 'last 2d'.
Get the most recent logs from all projects. Use this to see what's happening right now.
Get statistics about captured logs: total count, projects, log levels distribution.
Output schemas are not documented. Tool descriptions state what each tool returns (e.g., 'Get statistics about captured logs: total count, projects, log levels distribution') but do not define the response field structure. LLMs cannot plan downstream operations or extract specific fields without knowing what's in the response object. This violates the 'Document the output schema' pattern and forces LLMs to guess at response structure.
Destructive and write operations lack confirmation or dry-run patterns. 'clear_logs' (description: 'Clear all logs from memory. Use with caution!') has no confirmation gate, no dry-run option, and no warning in the description about irreversibility. 'restart_process' modifies external state without a dry-run or confirmation step. Agents can trigger these unintentionally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 8 | - | v1 |
List all projects that have sent logs. Shows which log agents are connected.
Restart a running process being monitored by an agent. Works in both TUI (watch) mode and one-shot mode. The agent will gracefully stop the current process and start a new one with the same command.
Search logs by text content. Returns matching logs with context. Supports both simple text search and regex patterns.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent from all tool definitions. These hints help LLMs reason about side effects and retry safety. The evaluation context provides risk classifications (READ_ONLY, DESTRUCTIVE, WRITE), but these are not encoded in the tool schema itself per the current MCP spec (2026-07-28).
Parameter constraint documentation is incomplete. The 'count' parameter in get_recent_logs states '(default: 50, max: 500)' in the description but does not specify minimum (0? 1?) or whether the max is enforced. The 'limit' parameter in search_logs says 'default: 50' but does not mention a maximum. Undocumented limits invite LLMs to pass absurd values or rely on trial-and-error behavior.
Error handling and recovery guidance are not visible in tool definitions. No tool description explains what error conditions might occur (e.g., 'project not found', 'invalid time format', 'regex compile error') or how the LLM should respond. This violates the 'Error responses must tell the LLM what to do next' pattern and leaves agents without guidance on retries or self-correction.
'clear_logs' has an extremely brief description ('Clear all logs from memory. Use with caution!') that does not explain consequences or irreversibility. It lacks any indication that this is a destructive operation beyond the cautionary phrase. The description should state 'This permanently deletes all captured logs and cannot be undone. Use only if you intend to reset the log store.' and should require confirmation.
'get_stats' and 'list_projects' have empty inputSchema properties ({}), which is correct for no-parameter tools, but their descriptions lack detail about what fields will be returned. 'Get statistics about captured logs: total count, projects, log levels distribution' tells the LLM what info exists but not the response field names or types. 'Show which log agents are connected' is vague about the return structure.
The 'startTime' and 'endTime' parameters in 'get_logs' and 'get_analytics' accept multiple types (string | number) and describe three different formats (ISO 8601, timestamp, relative). The description is helpful, but the schema itself does not enforce this multi-format contract. An LLM might pass an invalid format (e.g., 'January 15, 2026') and fail. Consider adding oneOf schemas or a pattern constraint.