Skip to main content
Glama
boundarycraftlab

authority-webhook-mcp

README.md
# Authority Webhook MCP

A small, public-ready Node.js MCP server with one consequential boundary: publishing a normalized release notice to a configured webhook.

The server deliberately separates four concerns:

1. MCP input validation.
2. Exact action and target normalization.
3. The host-owned `ReleaseProvider` boundary.
4. Provider result evidence.

With no configuration it uses a deterministic dry-run provider. Set `RELEASE_WEBHOOK_URL` to use the HTTP provider; HTTPS is required except for localhost test endpoints. No production credential is needed to run or test the project.

## Why this repository exists

Agent tools often place review or approval logic too early, before the final target and payload are known. Here the exact seam is explicit in `ReleasePublisher.publish()`:

```text
MCP request
  -> validate
  -> normalize action class + webhook target + exact input
  -> ReleaseProvider.send(action)   <-- consequential provider call
  -> correlate provider result
```

That seam makes the project suitable for evaluating a single-use authority gate without using a live external service.

## Requirements

- Node.js 20 or newer
- npm

## Run the checks

```bash
npm install
npm run ci
```

## Run as an MCP server

Dry-run mode:

```bash
npm run build
npm start
```

Local webhook sandbox:

```bash
RELEASE_WEBHOOK_URL=http://127.0.0.1:8787/releases npm start
```

The exposed tool is `publish_release_notice`:

```json
{
  "repository": "example/agent-tools",
  "tag": "v1.2.0",
  "summary": "Add a sandboxed release-notification tool."
}
```

## Run a deterministic evidence demo

The demo exercises the real normalization and provider boundary with the
in-memory dry-run provider. It performs no network request and prints the exact
action, its SHA-256 fingerprint, and the correlated provider result:

```bash
npm run demo
```

The dry-run provider request ID is derived from the action fingerprint, making
the output reproducible and easy to compare without exposing credentials.

## Current safety properties

- Repository identifiers are normalized to `owner/name`.
- Release tags and summaries have bounded formats.
- Webhook URLs reject embedded credentials and non-HTTPS remote targets.
- The action fingerprint covers the action class, exact target, and exact normalized input.
- Invalid input fails before the provider runs.
- Tests use an injected recording provider and make no external calls.

This baseline does not yet implement human approval, single-use consumption, tamper rejection, or replay protection. Those controls belong immediately before `ReleaseProvider.send()` and should be added only as a deliberate authority-gate integration, with tests that prove the provider remains untouched on every rejected path.

## License

MIT

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The single tool's purpose is clearly described, so agents can unambiguously select it.

Naming Consistency5/5

The sole tool follows a clear verb_noun pattern (publish_release_notice), making it predictable and consistent within the set.

Tool Count3/5

A single tool is minimal, which feels thin for a server named 'authority-webhook-mcp'. However, the tool is narrowly scoped to release notices, so the count is borderline rather than egregiously insufficient.

Completeness4/5

The tool covers the core action of normalizing and publishing a release notice, with a dry-run fallback. Missing are operations like configuration validation or history, but the primary workflow is complete.

Maintenance

ActivitySlowing
ResponsivenessNo issues