
Webhook Crash Lab
io.github.Krrishkumar125Published by GitHub account Krrishkumar125v0.2.4Updated Oct 29, 2026
Lets coding agents crash-test webhook handlers and re-run until they survive retries.
Overview
Local MCP server that lets a coding agent crash-test webhook handlers against retries, duplicates and forged signatures, then re-run until they pass.
- What you can do
- Run the crash lab against a config file, optionally with selected scenarios and a report path, returning failures with fix hints in fix order
- Run a built-in demo in broken or fixed mode to see the loop without any config
- Explain an existing JSON report, for example one produced in CI
- List every available scenario with what it checks, why it matters and how to fix it
- Return results as text plus structured content, with config errors reported as error results rather than crashes
- When to use it
- Useful when an agent writes or reviews webhook handlers (for example Stripe-style endpoints) and you want a repeatable loop of run, read structured failures, fix and re-run before shipping. Also handy for interpreting a crash-lab report generated in CI.
- Requirements
- Runs as a local stdio process, typically started with npx from the npm package webhook-crash-lab-mcp; Node.js and network access for the package download are needed. A crash-lab config file (JavaScript or TypeScript) pointing at a target server is required for the main tool; the demo needs no config. No accounts, API keys or environment variables are declared.
Installation
In SourceWeft
- Open Webhook Crash Lab in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
webhook-crash-lab-mcp
Coding agents write webhook handlers that work for one test event and break in production on retries, duplicates and forged signatures. This package gives them a loop: run webhook-crash-lab → read structured failures with fix hints → fix → re-run.
It ships three things:
Tools
Every result comes back as text for the model and structuredContent (with an outputSchema) for clients.
Errors such as a missing or invalid config come back as isError results, not crashes.
60-second start
[Install in VS Code] [Install in Cursor]
Claude Code
Codex
Cursor / other MCP clients
The examples pin the version so npx never silently runs a newer release. To update, check the latest with npm view webhook-crash-lab-mcp version, read the releases, then change @0.2.4 to the new version in your MCP config and restart the client.
Then ask: "Run the webhook crash lab demo", or "Make my Stripe webhook pass webhook-crash-lab".
Paste docs/AGENTS-snippet.md into AGENTS.md / CLAUDE.md to make it a standing rule.
Safety
run_crash_lab imports your crash-lab config (.mjs/.js/.cjs, or .ts/.mts/.cts via the bundled jiti) (it is code, like any config file) and sends requests to
its target. Point configs at a local server and a test database and secret only. The skill tells
agents never to use production URLs or live secrets.
Related
- webhook-crash-lab: the CLI/library this wraps
- eslint-plugin-webhook-safety and eslint-plugin-bullmq: the same bugs, caught statically
Sibling packages
Other tools by the same author:
- secret-blast-radius: what a malicious npm install could steal, plus a rotation plan
- zod-india: Zod schemas for GSTIN, PAN, IFSC, UPI and Aadhaar
- create-bullmq-app: scaffold a production BullMQ + TypeScript service
- webhook-crash-lab: crash-test webhook handlers against duplicates and races
- eslint-plugin-bullmq: lint rules for BullMQ production pitfalls
- eslint-plugin-webhook-safety: lint rules for unsafe Stripe webhook handlers
License
MIT © Krrish Kumar
Source: README.md at commit 477feed
Tools
0Version history
1- v0.2.4LatestOct 29, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts