> ## Content Index
> Fetch the complete content index at: https://aresa.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# One Webhook Product, Four Interfaces, and the Drift Between Them
- URL: https://aresa.me/signalbin-four-interfaces-drift/
- Published: 2026-08-26T20:39:48.000Z
- Updated: 2026-08-26T20:39:48.000Z
- Description: Signalbin exposed the same product through a web UI, REST API, MCP server, and agent skill. Their shared backend did not keep their capabilities aligned.
- Author: Alex Oleshkevich
- Tags: Dev Log, Signalbin

Signalbin exposes one webhook product through four interfaces: the web application, REST API, MCP server, and downloadable agent skill. They share backend concepts, but that did not keep their capabilities aligned. Destination management and replay shipped in the product while the agent-facing surfaces lagged behind.

The gap was found during an interface audit in August 2026\. It was repaired, but the cause is more useful than the individual missing tools.

## Shared code does not create product parity

The web UI can make a REST request without needing a separate backend operation. An MCP client needs a registered tool with an input schema, permission scope, handler, result schema, and description. An agent skill then needs prose that tells an agent when and how to use that tool.

Adding destinations to the database and REST API therefore completed only part of the feature. The MCP server initially lacked destination operations and replay, and the skill could not teach capabilities that did not exist there.

Signalbin's [MCP integration](https://signalbin.work/docs/guide/mcp-integration?ref=aresa.me) uses the same API tokens and scopes as the REST API. Its [downloadable skill](https://signalbin.work/docs/guide/skill?ref=aresa.me) is another public contract, served in a form agents can discover. Authentication can be shared while capability still drifts.

## Each interface needs an explicit mapping

The repair added MCP tools for listing, creating, updating, and deleting destinations plus replaying a captured webhook. Each tool maps to a REST operation and declares the matching read or write scope.

Tests now exercise the tools, their workspace isolation, and their result shapes. One table in the test suite records the intended REST counterpart for each destination tool. That is stronger than counting registered tools because a count can remain stable while the wrong capability is missing.

The skill and public documentation also had to change. A tool that exists but is absent from the agent instructions is technically callable and practically undiscoverable. Conversely, prose that describes an unregistered tool creates a failure at runtime.

## Drift needs a release gate, not memory

The audit exposed a missing invariant in the repository: nothing forced a feature author to consider all four interfaces. The durable gate is a small capability matrix attached to the feature:

| Capability          | Web | REST | MCP | Skill      |
| ------------------- | --- | ---- | --- | ---------- |
| List destinations   | yes | yes  | yes | documented |
| Change destinations | yes | yes  | yes | documented |
| Replay a webhook    | yes | yes  | yes | documented |

The entries should link to executable tests or generated definitions where possible. Hand-maintained matrices can drift too, but they make omissions visible during review and give automation something concrete to compare.

Multiple interfaces are not thin skins over one product. Each is a contract with its own discovery, permissions, errors, and release artifacts. Reusing the backend reduces implementation work, while parity still has to be designed and tested.