Publishing needs no identity at all, and the token returned at creation is what proves ownership afterwards: update in place, delete, or list what is yours. Lose it and the page stays up until its TTL expires. That trade is what makes this useful for an agent that needs to hand a human a link right now — a report, a preview, a JSON payload — without a deployment pipeline existing first.
A client for BrewPage, an instant hosting service. One call publishes content and returns a public HTTPS URL plus an owner token; the token is what lets you update or delete that resource later.
- HTML or Markdown published to a public URL, with optional password, a time-to-live in days, a filename and an opt-in top toolbar — publish_html
- A whole site published from an array of path-and-content files, with an entry point you can override — publish_site
- An existing page updated in place, and a multi-file site fully replaced at the same URL, with the uploaded bundle becoming the complete new file set — update_html, republish_site
- A file uploaded by URL and rehosted — publish_file
- JSON documents published, fetched and updated — objects, arrays or JSON-encoded strings — publish_json, get_json, update_json
- A key/value store created and then read and written key by key — publish_kv, set_kv, get_kv
- Published pages fetched back, including password-protected ones — get_page
- Anything you own deleted with its owner token — delete_resource
- The public gallery searched, optionally scoped to your own resources with the owner token — search_gallery
- Platform-wide usage statistics, with the day boundary shifted to an IANA timezone if you need it — get_stats
No account and no API key — publishing is a single call and the owner token comes back with the URL, so keep it if you intend to update or delete. Run npx -y brewpage-mcp over stdio. BREWPAGE_URL overrides the API base, which defaults to https://brewpage.app. Resources are addressed by namespace and id.
One command — npx -y brewpage-mcp