Loading ToolBench
MCP server for Tideways performance monitoring integration with AI assistants
Five tools with complete schemas and descriptions, but quality is uneven. All tools have proper JSON Schema with types and descriptions, meeting baseline requirements. However, descriptions are verbose (194-250 chars avg) and lack clear WHEN-to-use guidance. Parameter descriptions are present but generic. No tool annotations (readOnlyHint). Error handling exists server-side but not surfaced in tool definitions. Output schemas are not documented. Tools follow verb_noun naming correctly (get_*, all read-only). No critical gaps, but falls short of A-grade polish.
Retrieve historical performance data in JSON format for a specific date with configurable granularity. Analyze daily, weekly, or monthly performance trends, transaction reports, and time-series metrics.
Retrieve and analyze recent errors, exceptions, and performance issues in JSON format for actionable insights
Retrieve aggregate performance metrics and system-wide statistics in JSON format. Use for monitoring overall application health, trends, and high-level performance overview (use get_traces for detailed individual request analysis).
Retrieve time-series performance summary data in 15-minute intervals in JSON format for trend analysis and historical comparison. Returns data aggregated in 15-minute time buckets showing requests, errors, and 95th percentile response times.
Analyze individual trace samples in JSON format for detailed bottleneck identification and performance debugging. Use for investigating specific slow requests, not system-wide statistics (use get_performance_metrics for aggregate data).
No output schemas documented. Tool descriptions state what is returned ('JSON format') but do not specify field names, types, or structure. LLMs cannot plan downstream operations or extract specific fields without knowing response shape.
No tool annotations (readOnlyHint). All five tools are read-only, but this is not declared in the tool definition. Agents cannot distinguish safe tools from destructive ones without explicit hints.
Descriptions lack WHEN-to-use guidance. 'Retrieve aggregate performance metrics' does not explain when to call this vs get_performance_summary or get_traces. Descriptions should disambiguate tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
get_performance_metrics has no required parameters. All params (ts, m, env, s) are optional with no defaults stated. Unclear what the tool returns if called with no arguments.
get_traces has 11 optional parameters with complex interdependencies (min_date requires max_date). Dependencies are not documented in parameter descriptions, forcing LLMs to guess valid combinations.