Loading ToolBench
An MCP server for managing Toxiproxy - a tool for simulating network conditions and injecting faults into applications for chaos engineering and testing
The server defines 13 tools with reasonable naming and mostly complete schemas using Zod. Descriptions are present and actionable for most tools, though some lack depth about when to use them vs alternatives. Parameter descriptions are good but error handling guidance is minimal. The tools follow a clear verb_noun pattern and are logically organized by domain (status, proxy management, toxic management, troubleshooting). However, output schemas are documented only via example text responses, not formal JSON Schema definitions. Security considerations are largely absent from parameter documentation. This lands solidly in the 'Fair' range, noticeable gaps in completeness but a functional, usable interface.
Add a bandwidth limiting toxic to simulate slow connections
Add a latency toxic to simulate network delays
Add a timeout toxic to simulate connection timeouts
Check current iptables NAT rules and provide cleanup commands
Check if the Toxiproxy server is running and accessible
Create a Toxiproxy proxy for a PostgreSQL database with port forwarding setup. You must specify the database port.
Create a Toxiproxy proxy for RabbitMQ with port forwarding setup
Output schemas are undocumented. Tools return text-formatted responses with no formal schema definition. LLMs cannot parse structured fields or chain results to downstream tools. Violates pattern:response-shaper.
Error handling provides no recovery guidance. When a tool fails (e.g., toxiproxy_request throws), the error message is a generic string. LLMs receive no hint about whether to retry, lookup a prerequisite, or ask the user for help. Violates pattern:recovery-guide.
Destructive tools (delete_proxy, reset_proxies) lack confirmation or dry-run support. An LLM could irreversibly delete all proxies without warning. Violates pattern:confirmation-request.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 5 | - | v1 |
Delete a Toxiproxy proxy entirely
Generate commands to test your proxy setup and diagnose issues
List all Toxiproxy proxies and their toxics
Remove a specific toxic from a proxy
Remove all toxics from all proxies and enable them
Diagnose network connectivity issues between application, proxy, and upstream services
Parameter 'proxyName' and 'name' are used inconsistently across tools. create_db_proxy uses 'name', but delete_proxy uses 'proxyName'. This forces the LLM to reason about field mapping and increases error likelihood. Should standardize on 'proxy_name' throughout. Violates mxe:response-field-naming principle.
Tool descriptions are missing context about when to use them. Example: list_proxies does not explain 'call this first to discover available proxies before adding toxics'. Violates pattern:tool-description.
No permission gates or audit logging. Tools that delete proxies or modify network behavior should declare required permissions (e.g., 'requires:network.admin'). No evidence of caller identity verification or action logging. Violates pattern:permission-gate and pattern:audit-trail.
Enum constraints for 'direction' (upstream/downstream) are correctly specified in schemas, but other free-form string parameters (proxy name, toxic name) lack validation. LLMs could pass invalid characters or SQL injection payloads. Violates pattern:constrained-input.