Security & Testing
hooks.bot
Provides tools to create disposable webhook endpoints, capture and inspect incoming requests, and diagnose webhook signature issues.
ENDPOINT 1
https://hooks.bot/mcp
MCP server metadata
- Name
- hooks.bot
- Version
- 0.1.0
hooks.bot gives you disposable webhook endpoints and a signature debugger. THE LOOP 1. create_endpoint — returns a URL like https://hooks.bot/h/{id} 2. Give that URL to the user and tell them to point their provider at it. 3. wait_for_request — blocks until something lands. Call this instead of asking the user to paste anything; it returns the captured bytes directly. 4. diagnose_signature with endpoint_id + request_id and the user's signing secret. WHAT diagnose_signature ACTUALLY DOES It does not merely check a signature. It rebuilds it across every plausible construction — body normalization, secret derivation, hash algorithm, digest encoding and signed-string layout — finds the one that reproduces the signature the provider sent, and reports which step differs from that provider's documented scheme. So a result is a proven cause, not a guess. Prefer it over reasoning about the user's code. READING THE RESULT - status "valid" means the signature verifies. Check the timestamp finding anyway: a valid signature can still be rejected for being outside the replay window. - status "diagnosed" means it does not verify and the cause was found. The first finding is the actionable one. - status "no-match" usually means the secret belongs to a different endpoint or environment, or the body was already parsed and re-serialized before you saw it — that last one cannot be undone from captured bytes. GOTCHAS WORTH KNOWING BEFORE YOU GUESS - Stripe and Svix/Standard Webhooks both issue secrets starting whsec_ and derive keys from them completely differently. Stripe uses the whole string; Svix strips the prefix and base64-decodes the rest. This is the commonest failure in the category. - Twilio signs the request URL plus sorted form fields, not the body. diagnose_signature needs the full webhook URL for Twilio. - Paddle's replay window is five seconds, not five minutes. Anything replayed from a log will trip it, and that is expected rather than the bug. Reference material is available as resources: hooks://guide for the full workflow, and hooks://providers/{provider} for any of stripe, github, svix, shopify, slack, paddle, twilio.
Known tools 5
CONNECT WITH APPROVAL
Client installation
Review this server and its permissions before adding it. Secret placeholders must be set locally.
Codex
~/.codex/config.toml
[mcp_servers.hooks-bot]
url = "https://hooks.bot/mcp"
enabled = true
Claude Code
.mcp.json
{
"mcpServers": {
"hooks-bot": {
"type": "http",
"url": "https://hooks.bot/mcp"
}
}
}
Claude Desktop
Settings → Connectors → Add custom connector
Name: hooks-bot
Remote MCP URL: https://hooks.bot/mcp
Add this remote URL as a custom connector in Claude Desktop. Availability depends on the user plan and workspace policy.
Cursor
.cursor/mcp.json
{
"mcpServers": {
"hooks-bot": {
"url": "https://hooks.bot/mcp"
}
}
}
Visual Studio Code
.vscode/mcp.json
Add to Visual Studio Code{
"servers": {
"hooks-bot": {
"type": "http",
"url": "https://hooks.bot/mcp"
}
}
}
Generic MCP
Client-specific MCP configuration
{
"name": "hooks-bot",
"transport": "streamable-http",
"url": "https://hooks.bot/mcp"
}
MCP Inspector
Run the official MCP Inspector locally and enter the indexed Streamable HTTP endpoint.
TRUST AND VERIFICATION EVIDENCE
Trust Data Available
BuiltWith Trust API v2 evidence for hooks.bot was fetched 2026-08-29T01:11:20.784Z.
hooks.bot is assessed as Neutral: No suspicious signals found, but no strong positive signal either
Evidence is source-attributed and does not guarantee that a third-party server is safe. Risk labels are conservative metadata heuristics.