# Hookdeck MCP

> Hookdeck manages your webhook infrastructure directly through conversation, letting you treat event routing like a chat command. You can list, create, and update connections, sources, and destinations without leaving your agent interface. It gives you deep visibility into every piece of data flowing through your system.

## Overview
- **Category:** developer-tools
- **Price:** Free
- **Tags:** webhooks, event-driven, api-integration, event-routing, observability

## Description

Running an event-driven application means dealing with webhooks—and webhooks are notoriously fragile. This MCP connects to Hookdeck, giving you total control over your entire webhook pipeline using natural language commands. You can instantly check how many sources feed into your system or pause a connection during maintenance without ever logging into the dashboard. Need to debug a weird routing issue? Fetch specific metadata for any source or destination using unique IDs. The Vinkius catalog makes this power available, letting you manage complex event reliability right from your chat client. You'll handle everything from listing connections and sources to updating rules or even manually retrying failed events, all through simple conversation.

## Tools

### cancel_event
Stops scheduled retries for a specific event.

### count_connections
Returns the total number of active connections in your account.

### count_sources
Counts the total number of webhook sources configured.

### create_bookmark
Creates a reusable bookmark for a specific request payload.

### create_connection
Establishes a new connection to route webhooks from one source to another destination.

### create_destination
Sets up a new endpoint where incoming webhook data will be sent.

### create_issue_trigger
Generates a new trigger that creates issues in an external system.

### create_source
Adds a new source endpoint to the webhook network.

### create_transformation
Builds a new data transformation rule to modify incoming payloads.

### delete_bookmark
Removes an existing request bookmark.

### delete_connection
Permanently deletes a specific connection route.

### delete_destination
Deletes an entire destination endpoint configuration.

### delete_issue_trigger
Removes an issue trigger from the webhook setup.

### delete_source
Permanently removes a source endpoint.

### disable_connection
Deactivates a connection, stopping event routing immediately.

### disable_source
Disables an entire webhook source from sending data.

### enable_connection
Restores normal operation for a previously disabled connection.

### enable_source
Reactivates a previously disabled webhook source.

### get_attempt
Retrieves details about a single, specific delivery attempt.

### get_connection
Fetches all configuration details for a specified connection route.

### get_destination
Retrieves the full configuration and status of a target destination.

### get_event
Gets comprehensive details about a single processed event.

### get_issue_trigger
Retrieves the configuration for a specific issue trigger.

### get_metrics_attempts
Returns delivery attempt metrics, showing success and failure rates over time.

### get_metrics_events
Provides statistics on event processing performance.

### get_metrics_queue_depth
Shows the current number of pending items waiting for each destination to process.

### get_metrics_requests
Delivers metrics on overall request volume and throughput.

### get_metrics_transformations
Presents data on how transformations are performing, including execution time.

### get_request
Retrieves the full payload and metadata for a specific webhook request.

### get_source
Fetches all details about a specific source endpoint configuration.

### get_transformation
Gets the full code and settings for a defined data transformation.

### list_attempts
Retrieves a list of past delivery attempts, including status codes.

### list_bookmarks
Lists all existing request bookmarks you've saved.

### list_connections
Pulls a list of every active connection route by name and status.

### list_destinations
Lists all configured destination endpoints.

### list_events
Provides a paginated list of recent processed events.

### list_issue_triggers
Displays a catalog of all issue triggers in your setup.

### list_requests
Lists the most recent webhook requests received by the system.

### list_sources
Provides a list of all configured source endpoints.

### list_transformations
Lists all defined data transformation rules.

### pause_connection
Stops event routing for a specific connection route immediately.

### retry_event
Forces a manual retry of a single, failed event record.

### retry_request
Attempts to resend data for a rejected or failed request payload.

### test_transformation
Runs specific transformation code against sample data to test its logic.

### trigger_bookmark
Replays a previously saved, bookmarked request payload through the system.

### unpause_connection
Resumes event routing for a connection that was paused.

### update_connection
Modifies an existing connection's rules or name without deleting it.

### update_destination
Updates the configuration details, such as URL or rate limits, for a destination.

### update_issue_trigger
Modifies the settings of an existing issue trigger.

### update_source
Updates configuration details or credentials for a source endpoint.

### update_transformation
Changes the actual code or logic of a data transformation rule.

### upsert_connection
Creates a connection if it doesn't exist, or updates it by name if it does.

## Prompt Examples

**Prompt:** 
```
List all my current Hookdeck connections.
```

**Response:** 
```
I've retrieved your connections. You have 3 active routes: 'Shopify-to-Lambda' (ID: conn_123), 'Stripe-to-Analytics' (ID: conn_456), and 'GitHub-Webhooks' (ID: conn_789).
```

**Prompt:** 
```
Pause the connection with ID conn_456 immediately.
```

**Response:** 
```
The connection 'Stripe-to-Analytics' (conn_456) has been successfully paused. Event routing is now suspended.
```

**Prompt:** 
```
How many webhook sources do I have?
```

**Response:** 
```
You currently have a total of 5 sources configured in your Hookdeck project.
```

## Capabilities

### Inspect Webhook Topology
List and retrieve details for every connection, source, destination, event, and request in your webhook setup.

### Control Data Flow State
Pause or resume specific connections, sources, or entire pipelines to control traffic during deployments or outages.

### Manage Infrastructure Assets
Create, update, and delete core components like connections, destinations, sources, and transformations programmatically.

### Debug and Audit Events
Get granular metrics on request volume, queue depth, or retrieve the full history of specific events and attempts for debugging.

### Force Data Recovery
Manually retry failed requests or events to ensure data integrity after a temporary failure.

## Use Cases

### Debugging a Failed Payment Webhook
The payment webhook failed after an update. Instead of logging into Hookdeck and manually sifting through logs, you ask your agent to 'get_metrics_attempts' for the relevant connection ID. The agent instantly shows which attempts failed and if they are retriable using 'list_attempts'.

### Pre-Deployment Traffic Control
A team is updating a destination endpoint. Before going live, you use your agent to call 'pause_connection' on the production route. This guarantees no data gets sent while you test, and then you run 'unpause_connection' when it's safe.

### Auditing Data Flow Changes
An integration specialist needs to know if a specific source is still active after a merge. They ask your agent to count sources using 'count_sources', then use 'get_source' for the problematic ID, confirming all rules are correct before proceeding.

### Replaying Test Data
You manually created a perfect test request bookmark. You tell your agent to 'trigger_bookmark'. This re-runs that exact payload through the entire pipeline—including any transformations—without having to copy/paste the data again.

## Benefits

- Avoid context switching. Instead of jumping into a web dashboard to check statuses, you just ask your agent for the connection list or current queue depth.
- Maintain reliability during deployments. If you need to test an endpoint change, use 'pause_connection' and then 'unpause_connection' directly in conversation, zero clicks required.
- Deep debugging access. Need to know why a request failed? Use 'get_request' or 'list_attempts' to pull the exact payload and error details instantly for root cause analysis.
- Build resilient pipelines. You can create new components—like running 'create_source' or setting up complex data handling with 'create_transformation'—without writing setup scripts.
- Control recovery efforts. If a critical event fails, you don't wait; you call 'retry_event' to force the system to reprocess the data immediately.

## How It Works

The bottom line is: You manage a complex, production-grade data pipeline using only conversation.

1. Subscribe to this MCP and provide your Hookdeck API Key.
2. Connect the key in your preferred AI client, giving your agent access to the full webhook control panel.
3. Tell your agent what you need—for example, 'Show me all connections that are paused' or 'Retry the last failed event for source XYZ'.

## Frequently Asked Questions

**How do I list all active connections using the Hookdeck MCP?**
You ask your agent to use 'list_connections'. It will retrieve a clean, formatted list showing the name and current status of every connection route you have set up.

**Can I test my data transformations with the Hookdeck MCP?**
Yes. You call 'test_transformation', giving it sample input data. The agent runs your code against that payload and reports back exactly what the output will look like, confirming its logic before deployment.

**What is the difference between listing sources and listing connections with Hookdeck MCP?**
Listing sources shows you *where* data originates (the input). Listing connections shows you *how* that data moves from one source to a specific destination (the route).

**If I need to fix a failed webhook, should I use 'retry_event' or 'retry_request' via the Hookdeck MCP?**
Use 'get_metrics_attempts' first. If you are retrying a known, specific failure instance, use 'retry_event'. If it was a general payload rejection, use 'retry_request'.

**How many tools does the Hookdeck MCP have?**
The Hookdeck MCP provides access to over 50 specialized functions for managing every aspect of your webhook infrastructure.