Skip to main content
Glama
kochetkov-ma

brewpage-mcp

by kochetkov-ma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

republish_site

Replace an existing BrewPage site's complete file set at the same URL, preserving its expiry. Pass single-page HTML or multi-file paths with the owner token.

Instructions

Republish (full-replace) an existing multi-file BrewPage site in place at the SAME URL/ID. Requires owner token. The uploaded bundle becomes the complete new file set — files absent from it are removed, new files added, matching files overwritten. Single-page: pass entryContent. Multi-page: pass files (array of {path, content}). Optional entry overrides the default index.html. Republishing preserves existing expiry. 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
idYesSite ID
tagsNoOptional tags (replaces the site's existing tags)
entryNoEntry file path, default index.html
filesNoMulti-file site: array of `{path, content}`. Mutually exclusive with `entryContent`.
ttlDaysNoIgnored: republishing keeps the existing expiry; a supplied value comes back as a ttl-ignored notice.
namespaceYesSite namespace
ownerTokenYesOwner token received when the site was created (required for republish)
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.6/5.0
Behavior5/5

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

With no annotations, the description carries the full load and does so well: it discloses destructive semantics ('files absent from it are removed'), the owner-token auth requirement, that republishing preserves existing expiry, and that a supplied ttlDays is ignored via a notice. Limits are enumerated and routed to get_limits, plus skip behavior for system/unsupported files.

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 destructive full-replace contract, then mode selection, then limits and error codes in a logical order. It is dense and the error-code catalogue is long, but essentially every sentence supplies actionable information rather than filler.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers what an agent most needs: destruction semantics, auth, limits, file-skip behavior, entry resolution, and status-code mapping. Nothing material is left for the agent to guess.

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 precedence semantics the schema lacks: entry resolution falls back to root index.html, then the shallowest HTML file, and ttlDays is explicitly inert. Mode pairing of `entryContent` vs `files` is reinforced rather than merely repeated.

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

Purpose5/5

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

States a specific verb and resource with scope: 'Republish (full-replace) an existing multi-file BrewPage site in place at the SAME URL/ID.' The parenthetical defines the exact semantics (full replace, same identity), which cleanly separates it from publish_site (new site) and update_html (partial edit).

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 mode-selection rules: single-page uses `entryContent`, multi-page uses `files`, and `entry` overrides the default entry. The 'in place at the SAME URL/ID' framing implies this is for replacing an existing site rather than creating one, but no sibling tool is named explicitly as an alternative (e.g., publish_site, update_html).

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

Deploy Server

Other Tools