Loading ToolBench
MCP server for TCP connectivity testing and network validation
Three tools with complete input schemas and descriptions, but quality is uneven. Tool names lack action verbs (tcping, validate_firewall_rule, network_scan are weak). Descriptions are adequate (100-150 chars) but lack WHEN/WHY guidance. Parameters are typed and mostly described, but lack constraints (enums, ranges, patterns). No output schema documentation. Error handling is generic. Missing idempotency hints for network operations.
Scan a range of ports on a target host
Test TCP connectivity to a host and port using tcping-like functionality
Validate firewall connectivity by testing multiple host:port combinations
Tool names lack action verbs. 'tcping' and 'network_scan' are nouns/commands, not verb_noun patterns. Should be 'test_tcp_connectivity' and 'scan_ports' to signal intent to LLMs.
No output schema documented. Callers cannot predict response structure. tcping returns TcpingResult with fields like 'success', 'responseTime', 'averageTime', these must be declared in tool definition so LLMs know what to extract.
Numeric parameters lack bounds. 'port' accepts 0-65535 but no constraint declared. 'timeout' and 'interval' unbounded, LLMs could pass negative or absurdly large values. Add min/max to schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Descriptions lack WHEN/WHY context. 'Test TCP connectivity' does not explain when to use tcping vs validate_firewall_rule. Add: 'Use for single host:port checks; use validate_firewall_rule for multi-rule validation.'
Error handling is generic. Code returns 'Error: <message>' without recovery guidance. Should categorize as retryable (timeout) vs user-fixable (invalid host) vs fatal, and suggest next steps.