Loading ToolBench
MCP server for raw TCP socket access with buffer management and triggers
TcpSocketMCP has well-structured tool definitions with complete JSON schemas and extensive descriptions. Naming conventions are clear and action-verb-based (tcp_connect, tcp_send, tcp_read_buffer, etc.). However, there are moderate gaps in parameter documentation consistency, missing output schema documentation, and weak error handling guidance. The server excels at describing complex behavior (encoding options, timing issues) but lacks machine-readable constraints and recovery paths for error cases. Tool composition is sound, each tool has a single responsibility and output from one step (connection_id) chains naturally to the next. The descriptions are notably longer than baseline (averaging ~400-600 chars per tool vs 194 char baseline), which aids LLM comprehension but risks token waste. All 10 tools have explicit input schemas with type declarations and most parameters are described, placing this in the B/C boundary rather than C/D.
Register a pattern trigger with auto-response for a connection.
Get information about a connection's buffer without reading it.
Clear all received data from connection's buffer.
Open a new TCP connection to any TCP service. ## Typical Workflow ``` 1. tcp_connect → returns connection_id 2. tcp_send using that connection_id 3. tcp_read_buffer using that connection_id 4. tcp_disconnect using that connection_id ``` ## Notes - Connection ID is auto-generated if not provided - **SAVE THE CONNECTION_ID** - You'll need it for ALL subsequent operations - Always close connections when done to free resources ## Error Conditions Returns error if: - Connection refused (service not running) - Host not found (DNS resolution failed) - Port out of range (not 1-65535) - Connection timeout - Duplicate connection_id specified
Close a TCP connection and free resources. ## Required Parameter - **connection_id** (REQUIRED): The ID of the connection to close ## Notes - Always close connections when done to free resources - All associated triggers are automatically removed - Buffer data is cleared on disconnect ## Error Conditions Returns error if: - Connection doesn't exist - Connection already closed
Minimal descriptions for utility tools. tcp_clear_buffer, tcp_buffer_info, tcp_list_triggers, tcp_list_connections have descriptions under 20 characters (only the title, no context for when or why to call them).
Missing output schema documentation. All 10 tools describe what they do, but none explicitly document their response structure (what fields are returned, types, whether a list is paginated, etc.). The rubric requires documented return types for A+ tools; this server lacks any documented response schemas.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
List all active TCP connections.
List all triggers for a connection.
Read received data from connection's buffer. ## Required Parameter - **connection_id** (REQUIRED): The ID from tcp_connect ## Format Options - **utf-8** (default): Text format, replaces invalid bytes with � - **hex**: Hexadecimal format for binary analysis - **base64**: Base64 encoded binary data ## Parameters - **index** (optional): Starting position in buffer - **count** (optional): Number of chunks to read - **format** (optional): Output format ## Usage Examples ## Important Notes - **Timing**: After tcp_send, received data may not be immediately available. Try: 1. Wait 1-2 seconds after sending 2. Call tcp_read_buffer multiple times 3. Use tcp_buffer_info first to check if data has arrived - Buffer stores all received data until cleared - Data is stored in chunks as received - Use hex format for debugging binary protocols - Index is 0-based - **tcp_read_buffer**: Actually retrieves and displays the data - **tcp_buffer_info**: Check if data exists without consuming it ## Troubleshooting - **Empty response?** Wait longer or check multiple times - network responses take time - **Partial data?** Keep reading - data may arrive in multiple chunks - **Binary data looks corrupted?** Use `format: "hex"` for binary protocols ## Error Conditions Returns error if: - Connection doesn't exist - Invalid format specified
Remove a trigger from a connection.
Send data over TCP connection. **Required**: connection_id (from tcp_connect), data **Encoding options**: - utf-8 (default): Text with JSON escapes (\r\n for CRLF) - hex: Plain hex pairs like "48656C6C6F" (recommended for precise byte control) - base64: Base64 encoded binary **Terminator**: Optional hex suffix like "0D0A" for CRLF **Important**: For protocols requiring specific line endings (HTTP, SMTP, IRC), use hex encoding to avoid JSON escape issues. Example: "474554202F20485454502F312E310D0A" instead of "GET / HTTP/1.1\r\n" **Important**: Only send pairs of hex digits for hex encoding (e.g., "0A" for LF, "0D" for CR) no escaping allowed. Returns: success, connection_id, bytes_sent
Weak error handling guidance. tcp_connect documents error conditions (connection refused, host not found, port out of range, timeout, duplicate ID) but does NOT provide recovery hints. Per the rubric's recovery-guide pattern, errors should tell the LLM what to do next (e.g., 'If connection times out, verify the host is reachable with tcp_list_connections'). No other tool documents its error conditions at all.
No confirmation or dry-run for destructive operations. tcp_send, tcp_disconnect, and tcp_clear_buffer modify state or destroy data but lack confirmation steps. Per the confirmation-request pattern, irreversible operations should support a dry-run or explicit confirmation to prevent accidental data loss.
Parameter constraints not fully machine-readable. tcp_send documents 'Port out of range (not 1-65535)' in description text, but tcp_connect's port parameter has no min/max in the schema. Similarly, tcp_send's encoding enum is properly declared, but optional parameters like 'index' and 'count' in tcp_read_buffer lack min/max bounds. Per the constrained-input pattern, numeric ranges should be in the schema, not just prose.
Incomplete parameter descriptions. tcp_add_trigger's 'pattern' parameter is described as 'Regex pattern to match' but doesn't explain what it matches against (presumably incoming data). The 'response' parameter says 'Response to send when pattern matches' but doesn't clarify encoding rules or that the response is sent automatically. tcp_remove_trigger provides minimal context.