An API token and an MCP server.

A build finishes and someone has to get it to a client. A report generates on a schedule and has to reach one person. You want that to be four lines in a script rather than a browser tab.

An API token and MCP

Create a token at /tokens, copy it once, revoke it whenever. Tokens carry a read or write scope, an optional expiry and a last-used time you can check.

Campsend speaks the Model Context Protocol at POST /mcp, authenticated with that token. Three tools: list your deliveries, get one with its full event history and send files you have already uploaded.

Point Claude or any MCP client at it and ask whether last week's delivery was opened. Give it a read-only token and it can look without being able to send anything.

Run the whole thing yourself

Campsend is open source under the MIT license. One server, your own object storage, your own SMTP service.

A self-hosted install has no storage limit and no delivery limit, because plans don't exist in that code. Quotas live in a separate distribution that extends it through one documented hook. Nothing is disabled to sell you an upgrade.

The self-hosting docs cover it from bin/setup to a Kamal deploy, and the code is on GitHub.

It writes down what happened

Every request and job emits one structured JSON event to standard output, carrying a request id, route, status, duration and the records involved. Email addresses, access tokens and file names are deliberately left out.

Alongside it, an append-only audit log records what people and machines did, joined to those events by request id. Ship the JSON wherever you keep logs and one row usually answers the question.

Where it doesn't fit

The MCP server sends files you have already uploaded through the browser. Uploading over the API isn't there yet.

It runs on one host with SQLite. That's a deliberate ceiling rather than an oversight, and it's documented.

There's a worked example on the blog: sending a file to a client from a shell script.