Skip to main content
Glama
Omkar2240

ChaosBull MCP

by Omkar2240
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

inject_response_corruption

Intercept matching browser requests and return malformed JSON, false content lengths, or truncated payloads to test whether web apps handle corrupted responses without crashing.

Instructions

Opens the browser, navigates to the application, and intercepts requests matching a URL pattern to return a malformed or corrupted response. Simulates protocol/transport level corruption and observes whether the UI crashes. Use to answer: does the app handle malformed JSON, content-length lies, or truncated payloads without crashing?

Input Schema

NameRequiredDescriptionDefault
urlYesURL of the page to test
wait_msNoMilliseconds to wait after navigation before checking state (default: 2000)
headlessNoWhether to run in headless mode (default: false, launches real browser so user sees application)
viewportNoViewport size (default: 1280×720)
corruption_typeYesType of corruption: malformed_json (unterminated JSON body), length_mismatch (content-length claims 99999 bytes but body is short), truncated (body cut off at truncate_at_byte)
preview_delay_msNoMilliseconds to pause after simulation before closing browser, allowing visual inspection (default: 2000)
truncate_at_byteNoByte offset to truncate at (only used when corruption_type is truncated)
fallback_selectorNoCSS selector for the fallback UI that should appear (e.g., '.parse-error')
intercept_patternYesGlob pattern for requests to corrupt (e.g., '**/api/data**')
keep_browser_openNoKeep browser window open after test completes so user can interactively inspect the app (default: false)
api_health_check_urlNoOptional backend or hosted API health check URL to verify before running chaos test. Aborts if backend is down or errors.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.2

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the load and does disclose real side effects: a real browser is launched by default, requests are intercepted client-side, and the UI is checked for crashes. It leaves out what happens on failure (missing selector, unreachable URL) and what permissions/setup the browser automation needs, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: mechanics first, then the question the tool answers. No restated title, no filler, and the behavior is front-loaded before the use case.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter chaos tool with no annotations and no output schema, the description covers the mechanism and the testing intent well and the schema covers every parameter. The remaining gap is the return shape: since no output schema exists, the description should say what the observation result looks like (crash detected, fallback selector matched or not).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all 11 parameters including the corruption_type enum and truncate_at_byte are already documented in the schema. The description adds no parameter-level detail beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb chain (opens browser, navigates, intercepts) and the exact resource (requests matching a URL pattern returning malformed/corrupted responses). Clearly differentiated from siblings like inject_latency or block_resources, which do not speak to response-body corruption.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use to answer: does the app handle malformed JSON, content-length lies, or truncated payloads without crashing?" gives a concrete situation for invoking it. It stops short of naming when to prefer simulate_api_failure, simulate_network_drop, or assert_chaos_handled instead, so an agent must still infer sibling boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools