Public Beta: Direct engineering support available. Join Discord →

Webhook MCP Server

A webhook MCP server exposes a webhook gateway to an AI agent as a set of tools the agent can call: list data streams, inspect deliveries, replay a failed event, test a transformation, tail delivery logs. The agent operates the pipeline the same way a human would in the console — without a browser, without a copy-pasted API key on every call, and without a bespoke wrapper around each REST endpoint.

Slashbin's programmatic surface is designed for this. A native Slashbin MCP server is on the roadmap; today an agent drives Slashbin end-to-end through the console REST API, authenticated with a bearer key. The operation list is published as an OpenAPI contract at https://console.slashbin.io/api/openapi.json — fetchable without a key, so an agent can discover the surface before it has one. Every operation a human can take in the console is declared there.

What "webhook MCP" means to an agent

The Model Context Protocol lets an agent discover and call tools at runtime. Applied to webhooks, the useful tools are the same operations you'd run during an incident:

  • Inspect — "show me the last 10 deliveries for the orders data stream" or "get the failed delivery wh_01H...".
  • Diagnose — "what stage did this event fail at — ingress, transform, or delivery?" using the stored per-stage evidence.
  • Repair — "publish this fixed transform, then replay the last hour of failed events through it."
  • Verify — "test the new transform against this payload and return the output; only publish if it validates."

That's the interaction pattern: a human describes intent, the agent chooses tools, and the pipeline stays observable at every step. See Webhook Debugging for the same walk from a human's perspective.

What ships today

The contracthttps://console.slashbin.io/api/openapi.json. Fetch this first: it declares every operation it registers, with its path, verb, parameters and response shape. It is the operation list; this page does not keep a second copy of it.

Console REST API — HTTP-native, authenticated with a bearer key. Every operation a human can take in the console (list data streams, fetch delivery logs, replay events, test and publish transforms) has an endpoint an agent can call. Two worked examples, both declared in the contract:

# List data streams
curl -H "Authorization: Bearer $SLASHBIN_API_KEY" \
  https://console.slashbin.io/api/data-streams
 
# Fetch recent delivery logs for a data stream
curl -H "Authorization: Bearer $SLASHBIN_API_KEY" \
  "https://console.slashbin.io/api/pipeline/delivery-logs?dataStreamId=$DATA_STREAM_ID&limit=10"

An agent with an HTTP tool (Claude via tool-use, an OpenAI Assistant with a function-calling tool, Claude Code via curl or fetch) can call these directly and parse the JSON. See Claude webhook integration for a worked example.

How to get an API key

  1. Sign in to console.slashbin.io and open Account → API Keys.
  2. Click Create key, give it a name, and copy the plaintext value immediately. It is shown once, at creation — after that, only the prefix and last four characters are visible.
  3. Send it as Authorization: Bearer <key> on every console API call — the bearerAuth scheme the contract declares.

Keys are org-scoped and revocable — delete a key from the same Account → API Keys screen to revoke it.

slashbin-cli

slashbin-cli is a published command-line client for this same console REST API. It ships today, and it is how a terminal or an AI agent drives console operations. Install it, authenticate it and see what it can do at the CLI documentation.

The CLI is an API client only — it does not tunnel webhooks to localhost.

For the command groups, run:

slashbin --help

Many of those groups are generated from the same contract the REST API publishes, and the list moves with it, which is why it is not reproduced here — a copy on this page would drift the moment a new operation ships. slashbin <command> --help gives the options on any group. The CLI is an API client only — it does not tunnel webhooks to localhost.

What's coming

  • A native Slashbin MCP server — same operations, same auth model, discovered over the Model Context Protocol. When it ships, agents that speak MCP will call Slashbin tools directly without a hand-written HTTP wrapper.

It is additive on top of the same REST surface the API already exposes today.

Why route agent traffic through a gateway

An AI agent acting on webhook data has the same reliability problem a human service does, plus one more: the agent will confidently act on whatever it receives. If a vendor's payload shape drifts, or a delivery is silently dropped, the agent takes the wrong action instead of noticing nothing happened.

Slashbin gives the agent:

  • One canonical schema per data stream via the Golden Model — the agent reads the same shape regardless of source.
  • Delivery evidence — every payload, transform result, and destination attempt is stored, so the agent can inspect what actually happened, not what it hoped happened.
  • Replay — when the agent (or the human reviewing it) finds a bug, the fix runs against the original event, not a re-fired test payload.
  • Fan-out — the agent doesn't have to be the router; one inbound event reaches every consumer that needs it.

The pattern is the same one that makes webhooks safe for humans in production — see Webhook for AI agents for the argument in full.

Related reading

  • Webhook for AI agents — the reliability argument for putting a gateway between vendors and agent consumers.
  • Claude webhook integration — using Claude Code and the Anthropic API against the console REST API today.
  • Webhook ETL — the category and the schema-first model the agent consumes.
  • Replay — how to re-drive a stored event through the current pipeline.