# Pipedream MCP

> Pipedream connects your entire serverless automation stack directly to your AI client. Use this MCP Server to manage Pipedream workflows, audit event sources, and inspect raw data payloads without needing the browser console. It lets you list full workflow definitions, check real-time webhook subscriptions, and retrieve recent transaction events from any connected source.

## Overview
- **Category:** ship-it
- **Price:** Free
- **Tags:** serverless, webhook, api-integration, event-processing, workflow-orchestration, data-pipeline, debugging

## Description

You've got Pipedream running your whole backend stack. This **MCP Server** connects that entire system directly to your AI client so you can actually manage it without opening the browser console. You don't have to click around or dig through tabs just to check what went wrong; you get all the data right here.

When you need an overview, you start by listing everything. You can run `list_workflows` to pull a comprehensive view of every single automation flow defined in your account. If that general list isn't enough, you can drill down using `get_workflow`, which fetches the entire step-by-step logic and full configuration status for any specific workflow instance you point it at. This gives you the complete picture of how your serverless logic is structured.

For managing data sources, the process works similarly. You'll run `list_sources` to get a list of every configured data source—whether it’s set up as a webhook or if it polls for data—and what its current status is. If you know which source caused trouble, you can use `get_source` to pull detailed configuration information on that specific event source, including exactly what its trigger mechanism is and how its polling settings are configured.

Checking the actual incoming traffic is where this thing shines. You can run `list_events` against a specified source ID; this pulls summaries of recent raw payloads—the real JSON or XML data—that passed through that Pipedream endpoint, which is critical when you're trying to debug why something failed. To map out how outside services are talking to your system, you run `list_subscriptions`, getting a list of every external API that’s subscribed via webhook. You can also check who you are connected as anytime by running `get_user` to pull basic identification data for the current user context.

Basically, this lets you manage your whole automation lifecycle in one place: **you** get an overview of all available event sources using `list_sources`, and if you need deeper metadata, you use `get_source`. You can see every webhook subscribed to external APIs via `list_subscriptions` and retrieve the full structure and configuration status for any workflow with `get_workflow`; this gives you visibility into both the flow's logic and its operational limits. When all else fails, running `list_events` lets you look at raw data payloads from a specific source ID to see exactly what information hit your system.

## Tools

### get_source
Retrieves detailed configuration information for a specific event source.

### get_user
Pulls basic identification data for the current user context.

### get_workflow
Fetches the full details and step-by-step logic of a single workflow instance.

### list_events
Lists and summarizes recent raw event payloads received from a specified source ID.

### list_sources
Returns a list of all active and configured data sources within the account.

### list_subscriptions
Retrieves a list of all webhooks currently subscribed to external APIs.

### list_workflows
Provides an overview listing every workflow defined in your Pipedream account.

## Prompt Examples

**Prompt:** 
```
List the active event sources parsing my Slack webhooks.
```

**Response:** 
```
You have 3 active HTTP Event Sources currently handling payloads. Source ID `src_xyz` (Slack Notifier) is polling normally, while `src_abc` (Stripe Charges) is temporarily paused due to rate limiting. Need to evaluate the recent transactions from Stripe?
```

**Prompt:** 
```
Pull the raw events sent to the source `src_xyz982`.
```

**Response:** 
```
I've pulled the 5 most recent events ingested by `src_xyz982`. The latest transaction executed 3 minutes ago captured a POST request with headers `{ 'content-type': 'application/json' }` and payload `{"user": "jane_doe", "action": "signup"}`. Wait, there's no email object attached. Should we review the workflow logic assigned to handle this?
```

**Prompt:** 
```
Describe the node logic in workflow `wf_AByDk`.
```

**Response:** 
```
Workflow `wf_AByDk` consists of 4 distinct steps: 1. `trigger_http` (Webhook inbound). 2. `format_data` (Custom code parsing Node.js strings). 3. `mysql_query` (Writes parameters to database). 4. `send_slack` (Dispatches confirmation notification). Everything appears fully active with zero deployment errors recorded. Would you like the explicit code logic in the `format_data` block?
```

## Capabilities

### List and Get Workflow Details
Retrieves the full structure, step-by-step logic, and configuration status of any Pipedream workflow.

### List Available Event Sources
Returns a list of all configured data sources, showing their type (webhook/poll) and current status.

### Get Specific Source Metadata
Retrieves detailed information about one specific event source, including its trigger mechanism and polling settings.

### List Active Webhook Subscriptions
Shows all external APIs connected via webhooks, allowing you to see which services are actively communicating with Pipedream.

### Retrieve Recent Raw Payloads
Pulls the last few raw JSON or XML payloads that passed through a specific Pipedream source for immediate debugging.

## Use Cases

### Debugging a Payment Failure
A user's payment webhook failed. Instead of jumping to the web UI, they ask their agent to run `list_subscriptions` to confirm the Stripe subscription is active, then call `get_source` for that source ID. Finally, they use `list_events` to pull the raw payload and see exactly why the payment data didn't format correctly.

### Auditing an Automation Chain
A team needs to know if a specific customer data flow exists. They first run `list_workflows` to get all IDs, then ask the agent to use `get_workflow` on ID `wf_xyz`. This reveals the full sequence of steps—from initial HTTP trigger through database writes.

### Checking for Stale Data Feeds
The DevOps team suspects a data source is failing silently. They use `list_sources` to check every configured endpoint, and then call `get_user` just to confirm the authentication context before deciding which sources need immediate attention.

### Mapping System Inputs
An automation builder needs a diagram of all incoming data. They use `list_subscriptions` to gather all webhook endpoints and cross-reference them with `list_sources` to ensure every input channel is accounted for in the system architecture.

## Benefits

- See the whole picture with `list_workflows`. Instead of clicking through pages, your agent reads all active workflow IDs so you know exactly what logic exists in your account.
- Debugging is instant. Use `list_events` to pull raw JSON payloads directly into your chat window, letting you see if data passed correctly from the source before it hit the workflow.
- Pinpoint connection issues by calling `list_sources`. You can verify if an event source (like a polling database) is active and what its current configuration limits are. No more guessing why a hook failed.
- Understand your external connections using `list_subscriptions`. It shows you exactly which APIs have webhooks set up, so you don't accidentally break a critical data feed.
- Review logic without leaving the chat. With `get_workflow`, you get the step-by-step breakdown of an automation chain—the ideal place to check for broken nodes or outdated code blocks.

## How It Works

The bottom line is, you manage complex automation logic using natural conversation instead of clicking through dashboards.

1. First, subscribe to this Pipedream server integration and provide your API Key.
2. Next, tell your AI client exactly what you need—for example, 'List all workflows that interact with Stripe' or 'Show the last 5 events for source XYZ'.
3. The agent runs the necessary tool calls (e.g., `list_workflows` then `get_workflow`) and returns a structured report directly to your chat window.

## Frequently Asked Questions

**How do I check all my webhooks with list_subscriptions?**
You run `list_subscriptions` and your agent returns a structured list of every external API connected. This lets you see exactly which services are sending data to Pipedream.

**What is the difference between get_source and list_sources?**
`list_sources` gives you an overview of all sources (like a table of contents). `get_source` lets you drill down into one specific source to see its detailed metadata and configuration settings.

**Can I use list_events to check for rate limiting?**
Yes. By running `list_events`, you can review the volume of transactions over a period. If the event count suddenly drops or shows specific error payloads, it suggests rate limits or an upstream failure.

**Does get_workflow show me the code logic?**
Yes, `get_workflow` provides the complete step-by-step sequence of the workflow. You see every node—the HTTP trigger, custom code blocks, and API calls—so you can debug the flow structure.

**What specific user details does the `get_user` tool return regarding my account scope?**
It returns your current API key's identity and associated permissions. This lets you confirm that your agent is operating within the expected organizational boundaries before executing complex pipelines.

**How do I use `list_workflows` to find all available automation paths?**
This tool provides an index of every workflow ID and its current deployment status. If you need to view the full step-by-step logic or configuration limits, you'll then use `get_workflow` with a specific ID from this list.

**What metadata can I retrieve about one data input channel using `get_source`?**
`get_source` pulls deep details for any single event source. You'll see its polling schedule, required webhooks, and current configuration limits without having to navigate the Pipedream console.

**If I use `list_events`, am I getting the full raw JSON payload or just a summary?**
It provides a summarized view of recent events, showing timestamps and basic headers. To get the complete, unaltered raw data body for deep debugging, you must reference the source's specific API endpoint documentation.

**Can the agent pull raw JSON payloads from specific Pipedream webhooks?**
Yes. Ask the agent to list recent events from a specific Event Source ID. It captures the physical payloads ingested, showing you the raw keys and headers automatically. This is perfect for debugging failed external API calls without leaving your environment.

**How can I trace the steps of my serverless workflow components?**
Request details on a given Workflow ID (`get_workflow`). Your agent will unpack the configuration boundaries, distinct step triggers, and deployment paths, letting you quickly verify logic flow arrays or parameter mappings without needing the web canvas editor.

**Can I have multiple Pipedream workspaces configured?**
Yes, by generating separate API keys per workspace in Pipedream and authenticating them in Vinkius against distinct agents. Use `get_user` to instantly verify which token and quota limit (profile allowances) you are currently mapped onto.