Loading ToolBench
MCP server for LastPing monitoring platform, providing tools to manage monitors, API keys, agents, incidents, and other monitoring resources
LastPing MCP server has 39 tools with mixed quality. Strengths: API key tools (create_api_key, list_api_keys, revoke_api_key) have excellent descriptions (150-200 chars), proper enums for scope parameter, and clear error guidance. Monitor and incident tools are well-named with action verbs. Weaknesses: 8 tools (register_agent, list_agents, get_agent, update_agent, delete_agent, list_destinations, create_destination, update_destination) lack visible descriptions in source, only tool names appear in test files. No input schemas visible for these 8 tools. Destination and agent tools show only names, not full definitions. Output schemas are not documented. Error handling is present for API key scope ceiling (max_scope field) but inconsistent across other tools. Composition is good, tools follow verb_noun pattern and chain well (e.g., list_monitors → get_monitor → set_route).
Add a note to an incident
Create an API key with optional scope parameter. Scope must be one of: read, write, admin. If scope is omitted, the API applies its default (write). Returns the created key with its actual scope.
Create a monitor (check) with schedule configuration. Returns the created monitor. If a monitor with the same slug exists, it is updated (HTTP 200) instead of created (HTTP 201).
Create a status page
Declare expectations for a run (steps, timeouts, etc.)
8 tools (register_agent, list_agents, get_agent, update_agent, delete_agent, list_destinations, create_destination, update_destination, test_destination, delete_destination) have no visible descriptions or input schemas in source code. Only tool names appear in test files. Cannot verify parameter types, constraints, or LLM-facing documentation.
Output schemas are not documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., what fields does create_monitor return? Does it include monitor_id for chaining to set_route?). Violates pattern:response-shaper.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Delete a monitor by ID
Delete a status page
Reconcile discovered monitors from a scanner. Forwards sources as a JSON array to POST /api/v1/discovery/reconcile. Sources must be a JSON array; null is rejected. Returns created, existing, and orphaned monitors.
Export monitors and related resources as Terraform configuration
Get alert templates
Get an incident by ID. Marks certain fields as untrusted (detail, run_id, events.rid, events.title, events.name, events.body_excerpt, events.body) to prevent injection attacks.
Get a monitor by ID, including its assertions, guards, and routes
Get ping instructions for a monitor. Returns comprehensive instructions including run_wrapper, hook_install, how_to, reporting_options, curl snippets, and guidance on expectations and discovery. This is a pure proxy to GET /api/v1/checks/{id}/ping-instructions.
Get a run by ID
Get run history for a monitor
List all API keys, including their scope and lineage (created_by_key_id for cascading revoke awareness)
List deliveries (notifications sent to destinations)
List incidents
List all monitors
List open incidents in the failure inbox
List status pages
Pause a monitor by ID
Resume a paused monitor by ID
Revoke an API key and every key it created, recursively. This cannot be undone. Use list_api_keys to see what hangs off this key before revoking.
Set an alert template
Set a route for a monitor
Snooze a monitor for a specified duration
Update a monitor by ID
Update a status page
Destructive tools (delete_agent, delete_destination, delete_monitor, delete_status_page, revoke_api_key) lack confirmation or dry-run support. Agents can irreversibly delete resources without a safety gate. revoke_api_key cascades to child keys, no confirmation step documented.
Parameter descriptions are minimal or missing for many tools. E.g., 'period_s' in create_monitor lacks units clarity, range bounds, or relationship to schedule_kind. 'expectations' in declare_run_expectations is described as 'Run expectations object' with no structure guidance. LLMs cannot infer valid inputs.
Error handling is inconsistent. API key tools document max_scope ceiling and actionable errors (e.g., 'scope may not exceed'). Other tools (monitor, destination, agent) show no error guidance in descriptions. Agents cannot self-correct on failures.