Skip to main content
Glama

brewpage-mcp

by io.github.kochetkov-ma
OverviewDiscussionsAdmin

Publish HTML or Markdown page

publish_html

Publish HTML or Markdown content to BrewPage (repository default limit 5 MiB). Returns its primary share link and owner token. Supports password protection, custom TTL, optional filename, and an opt-in top toolbar (showTopBar). When deliveryMode is omitted for a public page, the server may publish it on its own subdomain if the page needs browser features a BrewPage link does not provide; the result then includes deliveryModeReason and a delivery notice. Markdown raw HTML is allowlisted: scripts, styles, event handlers, forms and embeds are removed. Returns manageUrl, a private management link (grants control; not for public sharing). Secrets allowed; likely ones are flagged in notices. Private namespace + password suit secrets.

Input Schema

NameRequiredDescriptionDefault
formatNoContent format, default HTML. HTML or MARKDOWN; the server also maps aliases (md, text/markdown, file extensions, code languages) and detects unknown values from content, reporting the change in notices.HTML
contentYesHTML or Markdown content to publish
ttlDaysNoRequested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30 by default; owner caps differ), reporting each adjustment in notices; the returned expiresAt is the actual expiry.
filenameNoOptional original filename (≤200 chars). Used as title fallback when no <title>/<h1>; immutable on update.
passwordNoOptional password to protect the page
namespaceNonamespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Suits anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page, so it is unsuitable for secrets, tokens or personal data. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen.
ownerTokenNoOptional. Default: BREWPAGE_OWNER_TOKEN, else a new token per create.
showTopBarNoAdd a thin top toolbar (filename + Download button + theme toggle) on the served page. Default: hidden.
deliveryModeNoOptional delivery choice for a fresh publication, independent of password/namespace. Fresh sites and HTML-format pages outside public (including the default unlisted namespace) always use subdomain; an explicit path there still publishes, on subdomain, with a delivery notice. Everything else in any namespace (Markdown, code/text, files, JSON, KV, public HTML) defaults to path (Promotion); public HTML may automatically choose subdomain for browser features. When creation returns an existing publication, it keeps its actual mode and URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / namespace / description
      Previous value: -"namespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Use it for anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page: never put secrets, tokens or personal data there. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."New value: +"namespace=public: listed in the public gallery and the sitemap, so Google, Bing and AI search can find and index it and people can discover it. Suits anything meant to be found or shared: docs, guides, demos, portfolios, reports, landing pages. Public pages are served right on the brewpage.app domain, which gives them the strongest reach in search; a page whose code needs its own origin (cookies, storage) gets its own subdomain automatically. Anyone can find and read a public page, so it is unsuitable for secrets, tokens or personal data. Omit (default): private. Unlisted and not indexed; anyone who has the link can still open it. Lowercase only: 1-32 of a-z, 0-9, hyphen."
    • changedInput schema / properties / ttlDays / description
      Previous value: -"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30 by default; owner caps differ), reporting each adjustment in notices; use returned expiresAt."New value: +"Requested TTL: days as a number, or a string such as '2w', '36h' or '1 month' (default 15 days). The server rounds to whole days and clamps to the allowed range (1-30 by default; owner caps differ), reporting each adjustment in notices; the returned expiresAt is the actual expiry."
  2. First observed

TDQS

A4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: discloses the 5 MiB repository limit, that Markdown raw HTML is allowlisted with scripts/styles/event handlers/forms/embeds stripped, that manageUrl is a control-granting private link, that secrets are permitted but flagged in notices, and that the server may auto-select subdomain delivery with a deliveryModeReason. These are exactly the non-obvious traits an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, limits and return values in the first two sentences, which is the right ordering. It then spends several sentences on deliveryMode and Markdown sanitization that partially duplicate the schema, adding some bulk without new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no output schema, the description covers what is returned (share link, owner token, manageUrl, deliveryModeReason/notice), the size ceiling, sanitization behavior, and the secret-handling caveat. Nothing critical for a correct first call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter already carries a long, precise description, so the description's parameter mentions (password protection, custom TTL, optional filename, showTopBar, deliveryMode) are largely restatements. It adds little semantic detail the schema doesn't already supply, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Publish HTML or Markdown content to BrewPage') and states the return values (share link, owner token). The content-type scope implicitly separates it from publish_file, publish_json, publish_kv and publish_site, though no sibling is named explicitly and the boundary with update_html/publish_site is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The closing line ('Private namespace + password suit secrets') and the namespace parameter's public-vs-private discussion give some selection context. However, there is no explicit guidance on when to use this versus update_html for an existing page, or versus publish_site/publish_file — the agent must infer the routing from content format.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All brewpage-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources