Skip to main content
Glama

publish_site

Publishes HTML sites as single-page content or multi-file bundles to BrewPage, returning a public URL and owner token for future updates.

Instructions

Publish an HTML site to BrewPage. Single-page: pass entryContent. Multi-page: pass files (array of {path, content}). Optional entry overrides default index.html. Use its returned primary link and retain the owner token. Limits (call get_limits for current values): 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 and what to do), 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.

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; use returned expiresAt.
passwordNoOptional password to protect the site
namespaceNoOptional. Omit to generate an unlisted namespace: anyone with its unpassworded link can read it, but it is excluded from gallery/search. Pass a custom namespace to group unlisted content, or pass `public` ONLY when the user explicitly wants gallery/search eligibility. Password-protected content stays excluded; unlisted, protected or otherwise ineligible native responses carry noindex; eligible public HTML, sites and files may permit indexing.
ownerTokenNoExisting owner token to group this site under the same owner as previous content
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. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: discloses site/request/file limits, that system files are skipped and never counted, that unsupported extensions and long paths surface in notices, TTL rounding/clamping behavior, and a full 400/413/422 error taxonomy. It omits auth requirements and whether re-publishing overwrites or creates new, so not a 5.

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?

Dense but front-loaded: the primary single-page/multi-page split comes first, then limits, then the entry chain, then errors. Each clause carries operational information, though the error-code block is tersely packed and would benefit from lighter grouping.

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-param mutation with no annotations and no output schema, the description covers limits, skipping behavior, entry resolution, error mapping, and hints at the return contract (primary link, owner token, expiresAt). The return shape is only partially described, which is the main residual gap absent an output schema.

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 baseline is 3, and the description adds genuine value beyond the schema: the entry resolution chain ('entry, else root index.html, else the shallowest HTML file') and the instruction to retain the owner token and use the returned primary link / expiresAt.

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?

States a specific verb and resource ('Publish an HTML site to BrewPage') and immediately splits behavior into single-page (`entryContent`) vs multi-page (`files`) modes. However, it never distinguishes itself from the sibling `publish_html` or `publish_file`, so an agent must infer the boundary between a 'site' and a 'page'.

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

Usage Guidelines4/5

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

Gives concrete selection criteria: single vs multi-page, when `entry` overrides, and entry fallback resolution. It also routes the agent to `get_limits` for current limit values. It stops short of naming sibling alternatives (publish_html/publish_file) or stating when NOT to use this tool.

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