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 projects, 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 at https://console.slashbin.io/api/…, authenticated with a bearer key. Every operation a human can take in the console has an HTTP endpoint the agent can call.

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 project" 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

Console REST API at https://console.slashbin.io/api/… — HTTP-native, authenticated with a bearer key. Every operation a human can take in the console (list projects, fetch delivery logs, replay events, test and publish transforms) has an endpoint an agent can call.

# List projects
curl -H "Authorization: Bearer $SLASHBIN_API_KEY" \
  https://console.slashbin.io/api/projects
 
# Fetch recent delivery logs for a project
curl -H "Authorization: Bearer $SLASHBIN_API_KEY" \
  "https://console.slashbin.io/api/pipeline/delivery-logs?projectId=$PROJECT_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

Sign in to console.slashbin.io and open Account → API Keys.
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.
Use it as Authorization: Bearer <key> against https://console.slashbin.io/api/….

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 the same console REST API. It runs today — no install step needed to try it:

npx slashbin-cli@latest --help

Install it globally if you use it regularly:

npm i -g slashbin-cli

It requires Node 20 or newer and is MIT-licensed.

The CLI uses the same bearer key documented above. slashbin login stores the key in a named profile, so shell sessions and shell-driven agents stop pasting the key on every call — the concrete difference from raw curl. It accepts a key non-interactively for CI and headless agents (slashbin login --key <key>), and --profile <name> selects between profiles for multiple orgs or environments.

The command groups are:

Command	What it does
`login`	Authenticate with slashbin.io
`whoami`	Show the authenticated user
`profile`	Manage authentication profiles
`projects`	Manage slashbin projects
`sources`	Manage webhook sources for a project
`destinations`	Manage destinations for a project
`transform`	Build and test transformation models
`openapi`	Export OpenAPI schemas for AI consumption
`logs`	View delivery logs for a project
`replay`	Replay webhooks for a project

Run slashbin <command> --help for 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 project 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.