Loading ToolBench
MCP server for Uptime Kuma — monitor management, heartbeats, status pages, and notifications for AI assistants
Strong foundation with 22 well-named tools using consistent verb_noun patterns (list_, get_, add_, edit_, delete_, pause_, resume_). All tools have descriptions (avg 120 chars, within 10-1024 baseline). Schemas are present and use Zod with type constraints. However, output schemas are not documented, LLMs cannot predict response structure. Parameter descriptions are present but often generic (e.g., 'The numeric ID of the monitor' lacks context on when to use which tool). Error handling is minimal, no recovery guidance or actionable error messages. Missing tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE). No confirmation pattern for destructive ops (delete_monitor, delete_tag, delete_maintenance).
Record a manual heartbeat for a push-type monitor.
Create a scheduled maintenance window.
Create a new monitor. Supports HTTP, ping, port, keyword, DNS, Docker, and many more types.
Assign a tag to a monitor.
Create a new tag for organizing monitors.
Delete a scheduled maintenance window.
Delete a monitor permanently.
Output schemas not documented. LLMs cannot predict response structure (e.g., what fields uptimekuma_list_monitors returns). Handlers return objects but no schema is visible in tool definitions.
Destructive tools (delete_monitor, delete_tag, delete_maintenance) lack confirmation pattern. No dry-run or confirmation step to prevent accidental deletion by agents.
Tool annotations missing. Risk levels (READ_ONLY, WRITE, DESTRUCTIVE) are documented in metadata but not exposed via MCP readOnlyHint/destructiveHint/idempotentHint. LLMs cannot infer safety properties.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Delete a tag.
Update a scheduled maintenance window.
Update an existing monitor. Only the provided fields will be changed.
Update an existing tag.
Get detailed information about a single monitor including its configuration and recent heartbeats.
Get heartbeat history for a specific monitor over the last N hours. Returns recent up/down events with response times.
List all scheduled maintenance windows.
List all monitors from Uptime Kuma with optional filtering by type, status, keyword, or tag.
List all configured notification channels (email, Slack, Discord, Telegram, etc.).
List all public status pages configured in Uptime Kuma.
List all tags used to organize and categorize monitors.
Pause a monitor (stop active monitoring).
Remove a tag from a monitor.
Resume a paused monitor (restart active monitoring).
Get an overall uptime statistics summary: total monitors, up/down/paused counts, and average uptime.
Error handling minimal. No recovery guidance (e.g., 'Monitor not found. Try uptimekuma_list_monitors to find valid IDs'). No error categorization (retryable vs user-fixable vs fatal).
Parameter descriptions generic. 'The numeric ID of the monitor' appears in 8+ tools but lacks context on when to use get_monitor vs list_monitors. No dependency hints or discovery guidance.