Skip to main content
Glama
biliman1-work

Proof Publisher MCP

README.md
# Proof Publisher MCP

A deliberately small TypeScript MCP server that publishes commit-bound proof
summaries to an HTTPS webhook. The project exists to make one consequential
external write easy to inspect, test, and place behind an authority boundary.

## Consequential boundary

The `publish_proof` MCP tool calls `ProofPublishingService.publish()`. The
service validates and normalizes the exact target, repository, full commit SHA,
and summary, then calls `ProofPublisher.send(action)`. The live implementation's
only external write is the `fetch()` POST inside
`HttpWebhookProofPublisher.send()`.

```text
MCP publish_proof
  -> normalize exact action + SHA-256 fingerprint
  -> ProofPublisher.send(action)       <-- authority seam
  -> fetch(allowed HTTPS origin)        <-- consequential provider call
```

Writes fail closed unless `ENABLE_WEBHOOK_WRITES=true`, and even then the
target must match `WEBHOOK_ALLOWED_ORIGIN`. Tests inject a recording provider;
they do not make network calls.

## Run the checks

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

## Run the MCP server

Read-only/fail-closed mode is the default:

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

To permit a real webhook write, an operator must explicitly configure both the
write switch and the only allowed origin:

```bash
ENABLE_WEBHOOK_WRITES=true \
WEBHOOK_ALLOWED_ORIGIN=https://hooks.example.com \
npm start
```

No credentials are stored in this repository. The project is intentionally
small so future approval logic can bind to the normalized action immediately
before the provider runs, without moving validation or external I/O into the
authority layer.

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusing it with another. The tool's purpose is clearly defined as publishing a proof summary to a webhook.

Naming Consistency5/5

The single tool name 'publish_proof' follows a clean verb_noun pattern, and with only one tool, there are no inconsistencies or mixed conventions.

Tool Count3/5

Having only one tool feels thin for an MCP server, and it falls below the typical 3-15 range. While the server's scope is narrow, the meager count makes the set seem insufficient for broader tasks.

Completeness4/5

The core action of publishing a proof is present and functional, but the server lacks supporting operations like querying published proofs or managing webhook allowlists. This leaves minor gaps that an agent might need to work around.

Maintenance

ActivitySlowing
ResponsivenessNo issues