Skip to main content
Glama
korb-sh

korb

Official
README.md
# korb

**Catch every webhook. Never drop one again.**

korb is a receive-side webhook gateway: point Stripe, Shopify, GitHub, or any
HTTP POST source at your korb URL, and korb verifies, stores, and fans events
out to your destinations — with retries, logs, and replay.

- Web: https://korb.sh
- GitHub: https://github.com/korb-sh/korb

Zero runtime dependencies. Node >= 18.

## Setup

```sh
npm i -g @korb-sh/korb
korb login           # approve access in your browser
```

`login` opens a device-style handshake and saves a token to
`~/.korb/credentials.json` (0600). For CI, create an API token in the
dashboard (Settings → API tokens) and export it:

```sh
export KORB_TOKEN=korb_...
export KORB_API_BASE=https://korb.sh   # override the default endpoint
```

## Commands

```
korb login / whoami / logout
korb forward <url> [--source id] [--interval ms]   live events -> localhost
korb sources / destinations / routes
korb events [--hours N] [--status s] [--source id]
korb events get <id>                               headers + body of one event
korb replay <id>                                   redeliver one event
korb presets                                       preset catalog (public)
korb test <source>                                 fire the preset's test event
korb delete <source|destination|route> <id-or-name>
```

## MCP server

`korb mcp` runs a [Model Context Protocol](https://modelcontextprotocol.io)
server over stdio — let your agent operate your webhooks: find failed
deliveries, inspect payloads, replay, fire test events.

Tools: `list_failed`, `get_payload`, `replay`, `send_test`
(replay + send_test need a read+write token; the server refuses politely on
read-only tokens).

Claude Desktop / Cursor config:

```json
{
  "mcpServers": {
    "korb": {
      "command": "korb",
      "args": ["mcp"],
      "env": { "KORB_TOKEN": "korb_..." }
    }
  }
}
```

Without `KORB_TOKEN` it uses the saved `korb login` credentials.

Typical agent flow: `list_failed` → what broke? → `get_payload` → what was
sent? → `replay` after fixing the consumer → `send_test` to verify
end-to-end.

## Scoped tokens

API tokens are minted in the dashboard and are read-only or read+write.
Write actions through a read-only token are refused locally (clear message)
and re-enforced server-side. Billing and account deletion are always
dashboard-session-only — a token can never touch them.

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool occupies a distinct stage of the webhook debugging workflow: list_failed discovers problems, get_payload inspects a specific event, replay redelivers one, and send_test generates a new test event. There is no overlap — an agent can unambiguously pick the right tool for each intent.

Naming Consistency4/5

All names use lowercase snake_case, and three follow a verb_noun pattern (list_failed, get_payload, send_test). 'replay' is a bare verb with no noun, a minor deviation, but the style remains readable and predictable overall.

Tool Count4/5

Four tools is reasonable for a focused webhook troubleshooting server, and each one clearly earns its place in the detect-inspect-fix-verify loop. It sits at the lean end of the ideal 3-15 range, but not awkwardly so.

Completeness4/5

The surface covers a full debugging lifecycle (list failures, inspect payload, replay, send a verification test), which is coherent and complete for the stated purpose. Minor gaps exist — no tool to list successful/all events or search/filter beyond failed deliveries — though the dashboard inbox mentioned in descriptions partly offsets this.

Maintenance

ActivityMaintained
ResponsivenessNo issues