brewpage-mcp

Republish site

republish_site

Destructive

Replace an existing BrewPage site in place at the same URL by uploading a complete new file set: new files are added, missing ones removed, matching ones overwritten. Requires 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: entryContent. Multi-page: files (array of {path, content}). Optional entry overrides the default index.html. Republishing preserves existing expiry. Old publications (made before 5 October 2026) are read-only: 409 OLD_PUBLICATION_READ_ONLY with createUrl to publish anew. Default limits (current: GET /api/limits): request 25 MiB; site 200 files, 5 MiB per file, 20 MiB total; path 380 characters. System files (.DS_Store, __MACOSX/ and similar) are skipped and never count; files with an unsupported extension or 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, no HTML file, or a PDF/Office file unreadable or password-protected; 413 = request over 25 MiB, too many files and form fields, or a file name/path too long; 422 = no servable file left; 503 = busy, retry after Retry-After seconds. BrewPage tokens and manage links must never be in public content. Page code must not hide or alter the BrewPage badge; a profile can turn the badge off for a page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "namespace": "<namespace>",
      "id": "<id>"
    },
    "name": "republish_site"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Site ID
`tags`	No	Optional tags; replace the site's stored tags. Omit to keep them.
`entry`	No	Entry file path, default index.html
`files`	No	Multi-file site: array of `{path, content}`. Mutually exclusive with `entryContent`.
`state`	No	Page data config, same shape as on create. Lists named here are added or updated, the others stay; a stored list keeps its `mode` and `write` when the call omits them. Omitted: the stored config stays; `null` turns page data off (saved entries are kept).
`ttlDays`	No	Ignored: republishing keeps the existing expiry; a supplied value comes back as a ttl-ignored notice.
`namespace`	Yes	Site namespace
`ownerToken`	No	Owner token from create. Default: env BREWPAGE_OWNER_TOKEN (local server only).
`entryContent`	No	HTML content for a single-page site (entry file). Mutually exclusive with `files`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.21.0Nov 12, 2026

addedInput schema / properties / state

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Page data config, same shape as on create. Lists named here are added or updated, the others stay; a stored list keeps its `mode` and `write` when the call omits them. Omitted: the stored config stays; `null` turns page data off (saved entries are kept)."
+}

Changed1 schema field changedv1.16.6Oct 31, 2026

changedInput schema / properties / tags / description

Previous value: -"Optional tags (replaces the site's existing tags)"New value: +"Optional tags; replace the site's stored tags. Omit to keep them."

Changed1 schema field changedv1.16.3Oct 30, 2026

changedInput schema / properties / ownerToken / description

Previous value: -"Owner token from create. Default: BREWPAGE_OWNER_TOKEN."New value: +"Owner token from create. Default: env BREWPAGE_OWNER_TOKEN (local server only)."

Changed3 schema fields changedv1.15.0Oct 27, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / files / items / additionalProperties
```
Removed value: -false
```

Changed2 schema fields changedv1.13.0Oct 25, 2026

changedInput schema / properties / ownerToken / description

Previous value: -"Owner token received when the site was created (required for republish)"New value: +"Owner token from create. Default: BREWPAGE_OWNER_TOKEN."

changedInput schema / required

Previous value: -[
-  "namespace",
-  "id",
-  "ownerToken"
-]New value: +[
+  "namespace",
+  "id"
+]

First observedv0.1.0Oct 23, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, and the description earns that by spelling out exactly what is destroyed: 'files absent from it are removed, new files added, matching files overwritten.' It adds non-obvious behavior beyond the annotations — expiry preserved, ttlDays ignored, system files skipped, badge-tampering restriction, and an error-code catalog including 503 retry-after.

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 action and its destructive nature before any parameter or error detail, which is the right ordering. It is dense and long — the limits enumeration and error-code list add bulk — but nearly every clause carries operational information an agent would otherwise have to discover by failing.

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 a 9-parameter destructive tool with no output schema, it covers prerequisites (owner token), size/count limits, path/extension skipping with notices, entry resolution order, and failure modes — a lot of ground. The notable gap is that it never says what a successful call returns (e.g., the resulting URL/ID), which matters since no output schema exists.

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, but the description adds real meaning: it maps `entryContent` vs `files` to single- vs multi-page modes, states `entry` overrides the default `index.html`, and warns that `ttlDays` is ignored on republish. It does not, however, explain `state` or `tags` semantics beyond what the schema already says.

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 precise verb+resource+scope: 'Republish (full-replace) an existing ... site in place at the SAME URL/ID,' which tells an agent this mutates an existing site rather than creating one. The distinction from publish_site is conveyed semantically ('existing', 'publish anew' via createUrl) rather than by naming the sibling, so it is clear but not maximally differentiated.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (existing site, same URL/ID) and when-not: pre-5-October-2026 publications are read-only and return 409 with a createUrl to publish anew instead. It also routes parameter choice conditionally — `entryContent` for single-page, `files` for multi-page — leaving little to inference.

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