# Webhook.site MCP MCP

> Webhook.site MCP lets you instantly create, manage, and inspect HTTP webhooks and API requests. You can generate custom URLs, capture raw payloads, set specific response codes, and test complex third-party integrations without setting up local tunnels or public servers. Perfect for debugging backend logic and validating callbacks in a conversational environment.

## Overview
- **Category:** developer-tools
- **Price:** Free
- **Tags:** webhook-testing, api-debugging, http-inspector, request-bin, payload-analysis

## Description

This MCP lets your agent function as an API testing rig. You stop guessing how external services talk to your system and start inspecting the data flow directly. It’s built for developers who need to test complex integrations, simulating everything from successful payments to malformed error responses.

The tool gives you control over the entire request lifecycle. You can define custom webhooks with specific aliases and expiration times. When a webhook fires—whether it's a payment processor or an external service—your agent captures every detail: headers, query parameters, and the raw payload body. Need to test how your app reacts to a 404 error? You use a function to set custom HTTP status codes and response bodies for that specific request. This whole process is designed to integrate into larger systems; for example, once you capture data here, you can easily chain it with another MCP in the Vinkius catalog—like passing the captured user ID directly to an email sending tool or a billing record creator—all within one agent conversation.

It’s pure debugging power. You get full visibility into every incoming request, and you never have to worry about where your keys sit; credentials pass through a zero-trust proxy that only uses them in transit.

## Tools

### create_action
Create a custom action for a token

### create_global_variable
Create a global variable

### create_token
Create a new Webhook.site token (URL)

### delete_action
Delete a custom action

### delete_global_variable
Delete a global variable

### delete_requests
Delete multiple requests for a token

### delete_token
Delete a token

### execute_action
Execute actions for a specific request

### get_requests
Get requests captured by a token

### get_token
Get details for a specific token

### list_actions
List custom actions for a token

### list_global_variables
List global variables

### list_tokens
List Webhook.site tokens

### set_response
Set dynamic response for a specific request

### update_action
Update a custom action

### update_global_variable
Update a global variable

### update_token
Update an existing token

## Prompt Examples

**Prompt:** 
```
Create a new Webhook.site token with the alias 'stripe-test' and a default 201 status.
```

**Response:** 
```
I've created your new webhook token. The URL is https://webhook.site/stripe-test (ID: 550e8400-e29b-41d4-a716-446655440000). It is configured to return a 201 Created status by default.
```

**Prompt:** 
```
Show me the 5 most recent requests received by token 550e8400-e29b-41d4-a716-446655440000.
```

**Response:** 
```
I found 5 requests. The latest one was a POST request from IP 192.168.1.1 containing a JSON payload with 'event': 'payment.succeeded'. Would you like to see the full headers for this request?
```

**Prompt:** 
```
Delete all requests for token 550e8400-e29b-41d4-a716-446655440000 that are older than 7 days.
```

**Response:** 
```
I have successfully deleted all requests received before 'now-7d' for the specified token. Your request history is now cleared of older entries.
```

## Capabilities

### Manage Webhook URLs
Create new webhooks with specific aliases, set expiry dates, and manage the overall collection of active webhook tokens.

### Inspect Incoming Requests
Retrieve detailed metadata for any incoming HTTP request, including headers, query parameters, and the full raw payload body.

### Simulate API Responses
Define custom HTTP status codes, headers, and response content to accurately mimic complex failure or success scenarios.

### Automate Token Actions
Execute pre-configured actions against specific webhooks, allowing you to automate parts of your development pipeline.

### Maintain State Variables
Create and manage environment-wide variables that allow you to track state across multiple webhook tests or debugging sessions.

## Use Cases

### Validating a Stripe Webhook Payload
A payments developer needs to confirm how their backend processes a `payment.succeeded` event from Stripe. Instead of setting up a local listener, they use the MCP to create a token and then ask the agent to capture requests hitting that URL. They inspect the raw payload using `get_requests` to verify every field is present.

### Simulating a Failure State
A QA engineer needs to test how the user dashboard behaves when an external service times out. They use the MCP's capability to define custom responses, telling the agent to set status 503 and a specific error message payload, allowing them to validate failure logic.

### Debugging Multi-Service Flows
A DevOps team is building an automation where receiving a webhook should trigger both logging and billing. They use the MCP to capture the initial request data; then they pass that clean payload through two different, chained MCPS (e.g., Messaging and Billing) to ensure the data integrity remains high across platforms.

### Cleaning Up Test Data
After a week of intense debugging cycles involving dozens of temporary webhook URLs, the developer uses `list_tokens` to see what's active and then executes `delete_token` on old or abandoned URLs to keep the environment clean.

## Benefits

- Stop relying on manual setup. You can use the `create_token` tool to generate a unique testing URL in seconds, letting your agent handle the rest of the debugging process.
- Don't just read logs; manipulate them. Use `set_response` to force a specific HTTP status code or body content. This lets you validate how your system handles error states (like 500 Internal Server Error) reliably.
- Need to debug state? The MCP lets you use functions like `create_global_variable` and `update_global_variable`. Your agent can track variables across multiple, distinct webhook calls, which is critical for complex multi-step processes.
- Clean up fast. When a test run is done, use the `delete_requests` tool to purge old data from a token's history, keeping your logs clean and focused on what matters.
- Build full workflows by chaining services. You can capture request data via this MCP and then feed that structured payload into another service MCP in the Vinkius catalog for processing.

## How It Works

The bottom line is that it gives you an API gateway interface inside your chat window, letting you manage complex webhooks without leaving your conversation flow.

1. First, your agent needs the Webhook.site API Key. You enter this key into Vinkius.
2. Next, tell your agent what you need—for example, 'Create a new webhook URL for my staging environment' or 'Show me all requests for token XYZ.'
3. The MCP executes the request, and your agent returns structured data, giving you access to the URLs, payloads, or historical logs needed.

## Frequently Asked Questions

**How do I start testing a webhook with Webhook.site MCP?**
Start by using `create_token` to generate a unique URL for your test. Then, tell the agent which token you want to monitor so it's ready when an incoming request fires.

**Can I use Webhook.site MCP to simulate a successful payment?**
Yes. You can define custom headers and body content using `set_response` to force the agent to return a 201 Created status with the specific JSON payload that simulates a successful transaction.

**What’s the difference between `get_requests` and `list_tokens`?**
`list_tokens` shows you all your available webhook URLs, while `get_requests` pulls the actual historical data—the payloads and headers—that have hit a specific token.

**Does Webhook.site MCP handle sensitive keys securely?**
Yes. Credentials pass through Vinkius's zero-trust proxy, which means they are used only in transit and never stored on disk anywhere the user's keys sit.

**What tool do I use if I need to purge old or unnecessary webhook payloads? (Using `delete_requests`)**
You should use the `delete_requests` tool. This lets you target and clear specific log entries from a token, regardless of how many were received. You can define time windows or criteria, which keeps your history manageable without losing important data.

**How do I simulate an API error response using the `set_response` tool?**
You configure this with `set_response`. This allows you to model failure scenarios by setting custom HTTP status codes, headers, and body content for a specific request. You can accurately test how your application handles various types of errors.

**Can I use `create_global_variable` to maintain state between different webhook calls?**
Yes, that’s the core purpose of global variables. By using `create_global_variable`, you store persistent data in your environment. This lets multiple unrelated webhooks read from and write to the same central state.

**If I create a token that is no longer needed, how do I properly remove it? (Using `delete_token`)**
You must use the `delete_token` tool. This command completely removes the webhook URL and all associated configurations from your account. It's important for maintaining a clean and secure environment.

**How can I create a temporary webhook URL that expires after one hour?**
Use the `create_token` tool and set the `expiry` parameter to 3600 seconds. You can also add an `alias` to make the URL easier to identify.

**Can I see the headers and body of the requests sent to my webhook?**
Yes! Use the `get_requests` tool with your Token ID. It will return a list of captured requests including full headers, query strings, and the raw payload content.

**Is it possible to make the webhook return a specific JSON response?**
Absolutely. Use the `set_response` tool to define a custom `content` (base64 encoded), `status` code, and JSON `headers` for any specific request received by your token.