Loading ToolBench
A local MCP server that exposes network diagnostic tools to Claude. Reproduces and extends the capabilities of the connectivity-agent project, exposing tools like ping, curl, tracert, nslookup, ipconfig, routing_table, http_timing, ssl_check, arp_table, and mtr.
The server provides 10 diagnostic tools with reasonable descriptions and clear READ_ONLY semantics. However, there are critical gaps: (1) NO input schemas are visible for any tool, all tools appear to be defined via @mcp.tool() decorators with Python type hints only, not JSON Schema objects. This violates the MCP spec requirement for explicit input schemas. (2) Parameter descriptions are minimal, most just say 'The hostname or IP address' with no guidance on format, constraints, or examples. (3) Output schemas are completely undocumented, tools return JSON but the structure is not formally specified. (4) Error handling is generic, run_command() returns {success, output|error} with no recovery guidance or error classification. (5) Descriptions vary widely in quality: some are excellent (e.g. http_timing, mtr), but others are sparse (e.g. ipconfig, routing_table). Per-tool scores range from 45 (routing_table) to 75 (mtr, ssl_check, http_timing). Overall fair but with significant schema documentation gaps.
Display the ARP cache showing all devices currently visible on the local network segment, with their IP and MAC addresses. Useful for network inventory and diagnosing local connectivity issues.
Fetch HTTP response headers from a host. Useful for verifying HTTP/HTTPS reachability, status codes, and server info.
Measure detailed HTTP connection timing for a host using curl. Returns a breakdown of: DNS lookup time, TCP connect time, TLS handshake time, time-to-first-byte (TTFB), and total time. All times are in seconds. Great for diagnosing slow connections.
Return the full network adapter configuration for this machine. Shows IP addresses, subnet masks, default gateways, and DNS servers for all active adapters.
Run a combined ping + traceroute analysis using WinMTR (Windows) or mtr (macOS/Linux). Shows per-hop packet loss and latency statistics — more detailed than tracert alone. Useful for pinpointing exactly which hop is dropping packets or adding latency. Takes approximately 10-15 seconds to complete.
Perform a DNS lookup for a hostname. Useful for diagnosing DNS failures or verifying DNS resolution is working.
No JSON Schema definitions visible in source code. All tools use Python type hints (@mcp.tool() with host: str, etc.), but there is no evidence of explicit JSON Schema objects with 'type' and 'description' fields. MCP protocol requires input schemas to be formally declared for each tool parameter.
Output schemas are completely undocumented. Tools return JSON (e.g., {success, output|error}), but there is no formal schema describing the response structure. LLMs cannot reliably parse outputs or plan downstream tool calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Ping a host to check network connectivity and measure round-trip latency. Sends 4 ICMP packets and reports success rate and average response time.
Display the system routing table. Shows how the OS decides where to send packets for different destinations, including the default gateway used for internet traffic.
Inspect the SSL/TLS certificate for a host. Returns certificate validity, expiry date, issuer, and subject info. Useful for diagnosing HTTPS errors or checking certificate health. The host can be a bare domain (e.g. 'amazon.com') or a full URL.
Trace the network route to a host, showing each router hop along the path. Useful for identifying where packet loss or high latency is occurring.
Parameter descriptions lack format constraints and usage guidance. 'The hostname or IP address to ping' does not specify: valid formats (FQDN, IPv4, IPv6), max length, whether localhost is acceptable, or what happens on invalid input. Descriptions should follow pattern: 'The target host (hostname, FQDN, or IPv4 address; 1-255 characters).'
Error handling is generic and non-actionable. run_command() returns {success: bool, output|error: str}, but does not classify errors as retryable, user-fixable, or fatal. An LLM receiving 'Command timed out after 10s' does not know whether to retry with a longer timeout, try a different tool, or give up.
Descriptions for ipconfig and routing_table are under 80 characters and lack context. 'Return the full network adapter configuration' and 'Display the system routing table' are too vague. LLMs need WHEN to use these tools: 'Call to diagnose local IP assignment issues, DHCP failures, or verify default gateway configuration.'
No input validation or constraint specification. Tools accept any string for 'host' parameter with no validation. An LLM could pass 'host='; cat /etc/passwd' or an absurdly long string. All user input should be validated (length, format) with clear error messages.