Loading ToolBench
A powerful MCP server that connects Claude to your monitoring stack (Prometheus, Grafana, Loki, PagerDuty, Slack) for automated incident response.
Server has 12 well-named tools with comprehensive descriptions (avg 180 chars, within baseline 194). All tools have input schemas with types and descriptions. However, output schemas are undocumented, LLMs cannot predict response structure for downstream chaining. Error handling is absent; tools return raw API responses without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification (READ_ONLY vs WRITE). Parameter descriptions are solid but lack format constraints (e.g., PromQL syntax rules, LogQL examples as enums). Missing idempotency guarantees for write operations.
Correlate alerts, metrics, and logs to diagnose an incident. This is the core intelligence tool. Pass in the outputs from: prometheus_get_active_alerts() → alerts, prometheus_get_metrics() → metrics, loki_get_logs() → logs. Returns: Incident severity (P1-P4), Probable cause with confidence level, Affected services and hosts, List of recommended actions, Incident summary. Always run this BEFORE generating a runbook.
Generate a structured step-by-step incident runbook. Supported incident types: memory_leak, high_cpu, disk_full, network_issue, database_issue, service_crash, deployment_issue, unknown. Returns a 4-phase runbook: Triage → Mitigation → Investigation → Resolution. Also includes a ready-to-use Slack communication template.
Create a Grafana annotation to mark an incident event on dashboards. This creates a visible marker on the timeline for post-incident analysis. Always create an annotation when an incident is declared (start) and resolved (end). Example text: '[P1 START] High CPU on prod-server-01 - Incident #42'
List available Grafana dashboards, optionally filtered by name. Returns dashboard titles, UIDs, URLs, and tags. Use this to find the relevant dashboard to share with the team during an incident.
No output schemas documented. LLMs cannot predict response structure (fields, types, nesting) for downstream tool chaining. E.g., prometheus_get_metrics returns dict but structure unknown, agent cannot extract time-series data reliably.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools marked 'WRITE' (silence_alert, create_annotation, create_incident, update_incident, slack_notify) lack destructiveHint=true, preventing agents from reasoning about side effects and retry safety.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Fetch logs from Loki using LogQL. Use this to investigate error patterns and correlate logs with alerts. LogQL examples: All logs from an app, Logs from a host, Error logs only, Kubernetes pod logs. Set level="error" to automatically filter for error-level messages.
Create a new PagerDuty incident and page the on-call engineer. Use 'high' urgency for P1/P2 incidents that require immediate response. Use 'low' urgency for P3/P4 incidents. Always include a clear title and detailed body with impact and symptoms.
List open PagerDuty incidents. Returns incident ID, title, urgency, status, service, and assignees. Use this to check if an incident has already been created before creating a new one. Status options: 'triggered', 'acknowledged', 'resolved' (comma-separated)
Update a PagerDuty incident status and optionally add a timeline note. Status: 'acknowledged' (working on it) or 'resolved' (incident closed). Always add a note when resolving to document what was done.
Fetch all currently firing alerts from Prometheus Alertmanager. Returns alert names, severity, labels, annotations, and start times. Use this as the first step when investigating any incident.
Query Prometheus time-series metrics using PromQL. Use this to investigate resource usage (CPU, memory, disk, network, latency). Common queries: CPU usage, Memory usage, HTTP error rate, Disk usage.
Silence a Prometheus alert for a specified duration. Use this to suppress known/expected alerts during maintenance or investigation. Always provide a clear comment explaining why you are silencing the alert.
Send a notification to a Slack channel. Severity controls the color and emoji: 'critical', 'warning', 'info', 'resolved'. Use 'critical' for P1 incidents, 'warning' for P2/P3, 'resolved' when fixed. Always notify the team when an incident is declared AND when it is resolved.
Missing error handling and recovery guidance. Tools return raw API responses without actionable error messages. E.g., if pagerduty_create_incident fails due to invalid urgency, agent receives raw error instead of 'Invalid urgency: must be high|low'.
Parameter constraints not formalized. 'status' in pagerduty_update_incident accepts enum [acknowledged, resolved] but no validation shown; 'severity' in slack_notify has enum but no validation. Agents may pass invalid values; tools should validate and return clear errors.
analyze_incident and generate_runbook accept optional dict inputs (alerts, metrics, logs) with no schema. LLMs cannot validate structure before passing; tools should document expected input format or validate and return clear errors.