playwright-network-chaos-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| simulate_api_failureA | Intercepts API requests matching a URL pattern and makes them return an error status code. Navigates to the page and checks if a fallback UI element appears. Use to answer: does the app show a proper error state when the payment API returns 503? |
| inject_latencyA | Adds artificial delay to requests matching a URL pattern, simulating slow networks or overloaded APIs. Use to answer: does the app show loading states when the API takes 3 seconds? Does it time out gracefully? |
| block_resourcesA | Blocks requests to specified URL patterns — useful for simulating third-party outages (analytics, CDNs, tracking). Use to answer: does the app still load and function if Google Analytics or a CDN is down? |
| simulate_network_dropA | Aborts requests matching a pattern after a delay, simulating a mid-flight connection drop. Use to answer: what happens if the network drops after the order request is sent but before the response arrives? |
| trigger_system_network_errorA | Aborts requests matching a URL pattern with a system-level network error code, simulating OS-level failures like unreachable hosts or access denied. Use to answer: does the app recover when the DNS resolution fails or the OS rejects a connection? |
| simulate_stateful_failureA | Intercepts requests matching a URL pattern and fails the first N requests with an error status, then lets subsequent requests succeed. Simulates transient failures and tests retry/recovery logic. Use to answer: does the app retry after a 503 and recover when the service comes back? |
| inject_response_corruptionA | Intercepts requests matching a URL pattern and returns a malformed or corrupted response, simulating partial network failures at the protocol level. Use to answer: does the app handle malformed JSON, content-length lies, or truncated payloads without crashing? |
| assert_chaos_handledA | Injects a chaos HTTP status into all matching requests, then returns a structured verdict: did the app show a fallback UI, were there unhandled JS exceptions, and did it survive? Use to answer: is the app chaos-resilient — does it show a recovery UI without throwing exceptions? |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct failure mode: error status codes, latency, resource blocking, mid-flight drops, system-level errors, transient failures, response corruption, and a combined assertion tool. While some tools share mechanics (e.g., simulate_api_failure vs simulate_stateful_failure), the descriptions clearly differentiate the behavior and use case, leaving no ambiguity.
All tool names follow a consistent verb_noun pattern, using verbs like simulate, inject, block, trigger, and assert. The naming is predictable, readable, and uniform across the set, with no mixed conventions or vague verbs.
With 8 tools, the set is well-scoped for a network chaos testing server. Each tool covers a distinct failure scenario without redundancy or bloat, fitting comfortably within the ideal 3-15 range.
The tool set covers a comprehensive range of network failure modes: error responses, latency, resource blocking, network drops, system-level errors, transient failures, and corrupted responses. It also includes an assertion tool for validating chaos resilience. A minor gap is the lack of an explicit reset/cleanup tool, though chaos may be scoped per test and reset implicitly.