Skip to main content
Glama

brewpage-mcp

by io.github.kochetkov-ma
OverviewDiscussionsAdmin

Publish site

publish_site

Publish an HTML site to BrewPage. Single-page: entryContent. Multi-page: files (array of {path, content}). Optional entry overrides default index.html. Returns its primary share link and owner token. Default limits (current values: GET /api/limits): a request is at most 25 MB; a site at most 200 files, 5 MB per file and 20 MB in total; each path at most 380 characters. System files (.DS_Store, __MACOSX/ and similar) are skipped and never count; files with an unsupported extension or a too-long path are skipped and listed in notices. Entry: entry, else root index.html, else the shallowest HTML file. Errors: 400 = a site limit exceeded (the message names it), invalid path or no HTML file; 413 = request over 25 MB, too many files and form fields, or a file name/path too long; 422 = no servable file left. 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
entryNoEntry file path, default index.html
filesNoMulti-file site: array of `{path, content}`. Mutually exclusive with `entryContent`.
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.
passwordNoOptional password to protect the site
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. A site always gets its own subdomain. 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.
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.
entryContentNoHTML content for a single-page site (entry file). Mutually exclusive with `files`.

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. A site always gets its own subdomain. 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. A site always gets its own subdomain. 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?

Far beyond the annotations: concrete quotas (25 MB request, 200 files, 5 MB/file, 20 MB total, 380-char paths), the skip-and-notice semantics for system files, unsupported extensions and long paths, the entry-resolution fallback chain, and a per-status error map (400/413/422). It also discloses what is returned (share link, owner token, manageUrl) and warns that manageUrl grants control and should not be shared publicly — exactly the kind of consequence detail annotations (readOnlyHint=false, destructiveHint=false) cannot carry.

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-loaded with the core call shape in the first sentence, then limits/errors, then the manageUrl caveat — a sensible ordering. The limit and error prose is dense and could be compressed (the parenthetical 'current values: GET /api/limits' and the repeated 'skipped' phrasing), but nearly every clause carries actionable information.

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

Completeness4/5

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

For an 8-parameter creation tool with no output schema, the description covers the payload shape, entry resolution, quotas, failure modes and the sensitivity of the returned manage token, which is what an agent most needs before calling it. The gaps are modest: deliveryMode's non-obvious enum behavior and the TTL clamping rules live only in the schema text, so the description is not self-sufficient for those parameters.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding meaning the schema does not, notably the entry-resolution precedence ('entry, else root index.html, else the shallowest HTML file') versus the schema's terse 'default index.html', and by tying namespace/password to the secret-hosting use case. It does not mention ttlDays, ownerToken or deliveryMode at all, leaving that half of the surface to the schema.

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?

Specific verb and resource: 'Publish an HTML site to BrewPage', with the single-page (entryContent) vs multi-page (files) shapes spelled out immediately. What it lacks is differentiation from siblings: publish_html and republish_site are never named, so an agent cannot tell from the description alone why it would choose publish_site over publish_html.

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?

Usage is implied rather than routed: 'Single-page: entryContent. Multi-page: files' tells the agent how to call it, and the private-namespace-plus-password advice gives a conditional recommendation. But there is no explicit when-to-use-this vs publish_html/republish_site guidance, and the closest thing to an exclusion ('not for public sharing' on manageUrl) is about the return value, not the call.

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