Pipedream MCP. Debug workflows and event data from chat.

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.