Skip to main content
Glama

brewpage-mcp

Republish site

republish_site
Destructive

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 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.

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
ownerTokenNoOwner token from create. Default: BREWPAGE_OWNER_TOKEN.
entryContentNoHTML content for a single-page site (entry file). Mutually exclusive with `files`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining that the uploaded bundle becomes the complete new file set, that absent files are removed, new files added, and matches overwritten. It also discloses owner-token requirements, expiry preservation, limits, skipped files, entry selection rules, and detailed error codes.

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?

The description is long but front-loads the core purpose and replacement behavior before moving into constraints and errors. The density is justified by the destructive operation and complex limits, though some parameter details repeat the schema.

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?

Given the destructive nature, eight parameters, and no output schema, the description is complete enough for correct invocation. It documents authentication, full-replace behavior, single-page vs multi-page inputs, expiry behavior, limits, skipped files, entry selection, and error conditions.

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%, so the schema already documents all eight parameters. The description adds useful context around entryContent, files, entry fallback logic, and ttlDays being ignored, but it largely repeats schema-level semantics and does not mention tags.

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?

The description states a specific verb and resource: 'Republish (full-replace) an existing multi-file BrewPage site in place at the SAME URL/ID.' This distinguishes the operation from initial publishing and makes the full-replacement semantics clear.

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?

The description clearly covers when this tool applies: an existing site, in-place republishing, and full replacement. It also notes the old-publication read-only case and directs the agent to createUrl to publish anew, but it does not explicitly compare against sibling tools such as update_html or publish_site.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.