Convoy MCP. Control webhooks from chat, not a dashboard.

Convoy lets your AI client manage your entire webhook pipeline—building, testing, and debugging event delivery without touching a dashboard or CLI. You'll use this server to control where events go, what triggers them, and whether they actually got through.

Endpoint Management: Building the Destinations.
You can define new destination URLs for incoming webhooks using create_endpoint, which builds and registers a single URL that waits for event data. If you need to completely wipe an endpoint off the system, you use delete_endpoint. You'll also run into situations where you need to modify an existing hook’s metadata or URL without deleting it first; then you call update_endpoint.

To keep tabs on your infrastructure, you can list every single registered destination using list_endpoints, and check the current status—active or paused—of a specific hook by calling get_endpoint. If things get noisy or need maintenance, you’ll use pause_endpoint to stop all traffic immediately, or activate_endpoint when you're ready for it to receive events again.

For massive projects, you can batch-register multiple hooks and subscriptions in one go using bulk_onboard; otherwise, start by setting up a single hook with create_endpoint.

Defining Event Logic: The Subscriptions.
To make sure your webhooks only fire when they should, you first define the structure of the data itself. You can use create_event_type to set up the schema and expected structure for a brand new kind of event data. If your data is too flexible and doesn't have a fixed shape, you create a variable payload using dynamic_event.

Once the type is defined, you build out the rules: you define what needs listening for with create_subscription, which tells a specific service to pay attention to certain event types and filters. To make those subscriptions highly precise, you set up granular conditions using create_filter to ensure events only fire if the payload meets exact criteria; you can speed this process up by running bulk_create_filters to set many rules at once.

For onboarding a complex service with lots of hooks and data streams, use bulk_onboard. If event structures come from an existing standard like OpenAPI, you skip the manual setup and run import_event_types to bring those definitions in automatically. You can also register new origins of data that generate events by calling create_source.

Testing and Delivery: Making It Fire.
When you want to test if your webhooks actually work, you have a couple of options for sending fake data. To fire a specific, targeted test event payload, you use create_event. If you need the system to send one single test event across every matching endpoint in your project—a full system check—you call broadcast_event.

A different scenario is when you need that single event sent out and distributed to several distinct endpoints at once; for that, you run fanout_event. For general testing purposes, if the schema isn't fixed ahead of time, you use a flexible payload via dynamic_event.

Debugging Failures: Tracking What Went Wrong.
When an event doesn’t fire or fails halfway through, you need to know why. You can check the history of all delivery attempts using list_delivery_attempts, and for more detail on a single failure, you retrieve full metadata by calling get_delivery_attempt to see if it failed or succeeded with errors.

If an event delivery did fail, you manually tell the system to try again using retry_event_delivery. You can also track the overall history of every past delivery through list_event_deliveries, and get a summary list of all active services and what they're listening for by calling list_subscriptions. For deep visibility into system changes or actions taken within the Convoy infrastructure, you check list_meta_events.