Loading ToolBench
Universal service health monitoring MCP server for checking APIs, databases, and services
Single-tool server with a well-structured HTTP endpoint checker. The tool has a complete JSON Schema with proper type definitions, enums, and numeric constraints. Description is clear and actionable (133 chars), exceeding the minimum. However, the tool lacks output schema documentation, error handling guidance, and does not describe what status values mean or how to interpret response times. The server follows basic MCP patterns but misses advanced error recovery patterns and result field documentation that would make agent integration seamless.
Check if an HTTP/HTTPS endpoint is healthy and responsive. This tool will test connectivity, measure response time, and validate status codes. Perfect for monitoring APIs, websites, and web services.
Output schema not documented. The tool returns a JSON response (implied from execute() returning a string), but the structure, field types, and possible values are not documented anywhere. LLMs cannot predict what fields to extract or how to chain downstream operations.
Error handling lacks recovery guidance. Errors are caught in src/server.ts with a generic error message format ('❌ Error executing tool...'), but the HttpHealthChecker does not classify errors (retryable vs terminal) or suggest remediation steps. E.g., a timeout should suggest 'increase timeout parameter', a DNS error should suggest 'verify URL format'.
Status values in HealthCheckResult ('healthy', 'unhealthy', 'warning') are not described in the tool documentation. An LLM does not know what triggers 'warning' vs 'unhealthy' or whether status=warning should halt a workflow. Add examples: 'warning: response time > 5s but status 200' and 'unhealthy: non-200 status or timeout'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Response format undefined. The HttpHealthChecker.checkEndpoint() method returns a HealthCheckResult object, but the tool's execute() method in check-http.ts is not shown. It likely serializes this to JSON, but without seeing the implementation, output field names and types cannot be verified. This violates the principle that output schemas must be documented.
No confirmation or dry-run step for a monitoring tool that could be misused. If an LLM repeatedly calls check_http_endpoint with a malformed URL or extremely short timeout, it could generate excessive traffic or API load. Consider adding a rate-limit note or suggesting batch operations via a separate tool.