Webhook.site MCP. Debug incoming webhooks and API payloads instantly.

Listen up. You need to test APIs and webhooks? Forget building local tunnels or writing boilerplate server code just for debugging. Webhook.site lets your AI agent handle all that right through the MCP Server. This thing gives you full control over inspecting, simulating, and automating complex HTTP interactions.

Token Management: Setting Up Your Test Environment

You start by getting an endpoint. You can call create_token to generate a brand new webhook URL—a unique token for your test. When you do that, you get control over the alias it uses and even set default response behaviors right when you make it. If you need to change those core settings later, use update_token.

For instance, if the endpoint expires too fast or its name is misleading, you modify those details with update_token.

You can see every token you've ever made by running list_tokens, which gives you a full directory listing of all active webhooks. If a test is done and you don't want the URL hanging around, use delete_token to permanently wipe out both the token and all its associated configurations.

Inspecting Traffic: What Happened?

When data hits your webhook, this server catches it for inspection. You call get_requests to pull a list of every single webhook that's been sent to a specific token ID; you get the full details on each one. This means you can read everything: raw headers, query parameters, and the entire payload body—you see exactly what your client sent over.

If you only want to wipe out the evidence after review, delete_requests clears all captured webhook requests associated with that token.

To make sure the data is clean for the next test cycle, you can manage state variables using global context. You use create_global_variable to establish a persistent variable that your agent needs to reference across multiple different testing sessions. If the environment gets messy, delete_global_variable clears out an environment-wide variable and its stored state.

You also control what data your agent sees by managing actions. You use list_actions to see all custom automation steps currently configured for a token. When you're ready to modify those rules, you call update_action, or if the setup is wrong, you run delete_action to remove it.

Simulation and State Control: Making It Behave

This isn't just reading data; you're actively controlling the conversation. You can force your webhook to behave like any API endpoint out there using set_response. This lets you manually set a dynamic HTTP response—you control the status code (like 401, 200, or 503), the headers, and even the body content for one specific captured request.

You validate client logic by simulating everything from complex API success to specific failures.

When an incoming request hits your token, you don't just inspect it; you automate a response using execute_action. This runs a pre-configured custom action against that request's history data, allowing for automated testing workflows based on the input. If you need to change the value of a shared context variable mid-test, you use update_global_variable to adjust the state for subsequent tests.

The Full Command Set

You can fetch the entire configuration details of an existing token with get_token. You'll see all available actions listed by running list_actions on a specific token. To manage your shared environment data, you check out all stored variables using list_global_variables.

This suite lets your agent build and test complex API interactions conversationally: generate endpoints with create_token, verify incoming payloads with get_requests, simulate failure modes with set_response, execute logic using execute_action, and maintain context across tests by controlling variables via create_global_variable or update_global_variable. You manage the entire lifecycle—from creation to deletion (delete_token)—without ever touching a command line.