Loading ToolBench
MCP Server implementation for Gonzales internet speed monitoring. Exposes speed test data, statistics, connection status, and ISP quality metrics to MCP-compatible AI clients like Claude Desktop.
The server defines 7 tools with clear verb-first names (get_*, run_*) that align with agentic patterns. All tools have descriptions and input schemas are present. However, there are significant gaps: parameter descriptions are minimal or absent in most cases, output schemas are not documented, and error handling guidance is missing. The rubric baselines show A+ tools have 100% of params with descriptions and documented return types, this server has neither. Tool descriptions average ~130 chars (within baseline range of 34-392), but parameters lack the depth needed for LLM reasoning. No tool has parameter constraints (enums, ranges), and no output structure is defined. The server is functional but falls short of production-grade quality for agentic use.
Check if the internet connection meets the configured speed thresholds.
Get the ISP quality score (A+ to F grade) based on speed, reliability, and consistency.
Get the most recent speed test result with download speed, upload speed, and ping latency.
List detected network outages within a time period.
Get speed test statistics including averages, minimums, maximums, and reliability scores.
Get a comprehensive summary of the internet connection status with alerts and recommendations.
Trigger a new speed test and return the results. This may take 30-60 seconds to complete.
Output schemas are not documented. No tool definition includes a 'result' or 'outputSchema' field describing what fields the response contains or their types. Rubric baseline: 100% of A+ tools have documented return types. This forces LLMs to guess at response structure and prevents reliable chaining to follow-up tools.
Parameter descriptions are missing or extremely sparse. The 'days' parameter in get_statistics and get_outages has minimal context ('Number of days to analyze / look back'). The rubric requires parameter descriptions to explain FORMAT, RANGE, and ALLOWED VALUES. No constraints like 'days must be 1-365' are present.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
No enum constraints on parameters despite clear bounded values. The 'days' parameter likely has sensible bounds (not -5 or 999999) but these are undocumented. Rubric: 'When a parameter accepts one of a known set of values, declare it as an enum. Free-form strings invite hallucinated values.' For numeric bounds, use minimum/maximum in the schema.
No error handling guidance or recovery paths documented. Tool descriptions do not explain what happens on failure (e.g., 'If speed test is already running, returns error code 429'). Rubric: 'Error responses must tell the LLM what to do next.' Without this, agents cannot handle failures gracefully.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in tool definitions. The server states 'Risk: READ_ONLY' or 'Risk: WRITE' in metadata but does not include these in the actual tool schema. Spec 2026-07-28 recommends structured tool annotations via the schema's metadata.
Tool descriptions do not explain WHEN to use each tool vs. similar ones. E.g., get_connection_status vs. get_latest_speedtest both appear to return speed/connectivity info, but their distinct purposes are unclear. Rubric: 'A tool description must answer: What does it do? When should the LLM call it instead of a similar tool?'
No pagination support documented. Tools like get_statistics and get_outages may return large lists (e.g., 30 days of outages), but there is no indication of limit, offset, or cursor parameters. Rubric baseline: tools returning lists should accept page/offset and limit parameters.