Skip to main content
Glama

Update site

update_site
Idempotent

Use when the user wants to push the new version, ship the changes they just made, or update the page while keeping the same link. Replaces a site's content in place by id. Accepts the same inputs as publish_site (HTML, a bundle, or a single document such as Markdown, .ipynb, PDF, .docx, .pptx, .xlsx, CSV, an image, a video, an audio, a Mermaid diagram or a text file, which is re-rendered; pass filename for a lone non-zip file, and include_original as on publish_site); the detected content_kind may change, and the result warns when html has replaced a site that was rendered from a file. Preserves the URL, visibility, allowlist, link expiry, and view password, and records a new version. Open viewers are offered a Refresh to the new content (a landing page, framed in the marketing site, shows it on its next load). Like publish_site, the new content is scanned for window.SNAPHOST data usage and any new collections are set up to match how the page uses them (reported in the result), and for external references the site's security policy will block; relay those to the owner and either trust the approved origins (add_external_origins) or vendor the assets. Relative references to files missing from the upload are reported too; include those files and republish.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoA single self-contained HTML document
site_idYesThe id of the site to update
filenameNoThe uploaded file's own name with its extension (`report.pdf`, `photo.png`, `data.csv`). Give it once, at create_bundle_upload; a name given here as well must match it. Pass it here only for a single non-zip file whose upload was opened without one, so it is rendered as its kind; an upload that no name describes and that is neither a zip nor an HTML page is refused. For a .docx, .pptx or .xlsx sent as `zipBase64`, give its name here: it heads the bar and names the download. Ignored for a .zip bundle. A name SnapHost does not take is refused with the export that would work.
printableNoThe page is built to print (a PDF that keeps the look): the design check asks for print styles, and a plain page gets the viewer's Print action (a report or a deck carries its own Download PDF button instead). Kept on later updates unless given again.
upload_idNoReference a bundle already uploaded via create_bundle_upload (sent with upload_bundle_part, or PUT to its `upload_url`); use this for a large or multi-file app (e.g. a built React site) that exceeds the inline `html`/`zipBase64` limit, or for a single file that is not a zip (Markdown, a notebook, a PDF, an image, a video, an audio, a CSV, a Mermaid diagram or a text file), sent as it is together with `filename`. Mutually exclusive with `html` and `zipBase64`.
zipBase64NoBase64-encoded .zip bundle (entry HTML + assets), for a multi-file bundle small enough to inline; a .docx, .pptx or .xlsx (zips themselves) or a one-entry zip holding a single Markdown, notebook, PDF, CSV, image, video, audio, Mermaid or text file under its real name also goes here. A single HTML document belongs in `html` instead: base64 has to be reproduced byte for byte and a long string often is not, so this input is rejected outright if the encoding or the archive checksums do not verify.
workspace_idNoOptional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for).
document_kindNoWhat the site is: a report, a presentation, a dashboard, or a plain page (the default). A publish or content update of such a site runs the design check (`design_warnings`); a presentation may go full screen. Kept on later updates unless given again.
include_originalNoWhether readers may download the uploaded file itself from the page. Applies to a Word, PowerPoint or Excel file only, and is off by default for them, because the file holds what the page does not show: speaker notes, hidden slides, sheets, rows and columns, formulas, comments and tracked changes. Pass true to offer it anyway; on update_site, leave it out to keep the live version's choice. A macro-enabled .docm, .pptm or .xlsm is never offered. A CSV, image, video, audio, PDF, diagram or text file is its page and always downloads; a Markdown file or notebook becomes its page and has no download. The result reports `original_included`, and `render_notices` says what the page could not show (cells shown as formulas when a workbook carries no computed values; a file left out for size). Relay a notice to the user.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / printable / description
      Previous value: -"The page is built to print (a PDF that keeps the look): the viewer then offers Print, and the design check asks for print styles. Kept on later updates unless given again."New value: +"The page is built to print (a PDF that keeps the look): the design check asks for print styles, and a plain page gets the viewer's Print action (a report or a deck carries its own Download PDF button instead). Kept on later updates unless given again."
  2. Changed2 schema fields changed
    • addedInput schema / properties / document_kind
      Added value: +{
      +  "description": "What the site is: a report, a presentation, a dashboard, or a plain page (the default). A publish or content update of such a site runs the design check (`design_warnings`); a presentation may go full screen. Kept on later updates unless given again.",
      +  "enum": [
      +    "page",
      +    "report",
      +    "presentation",
      +    "dashboard"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / printable
      Added value: +{
      +  "description": "The page is built to print (a PDF that keeps the look): the viewer then offers Print, and the design check asks for print styles. Kept on later updates unless given again.",
      +  "type": "boolean"
      +}
  3. Changed4 schema fields changed
    • addedInput schema / properties / filename
      Added value: +{
      +  "description": "The uploaded file's own name with its extension (`report.pdf`, `photo.png`, `data.csv`). Give it once, at create_bundle_upload; a name given here as well must match it. Pass it here only for a single non-zip file whose upload was opened without one, so it is rendered as its kind; an upload that no name describes and that is neither a zip nor an HTML page is refused. For a .docx, .pptx or .xlsx sent as `zipBase64`, give its name here: it heads the bar and names the download. Ignored for a .zip bundle. A name SnapHost does not take is refused with the export that would work.",
      +  "type": "string"
      +}
    • addedInput schema / properties / include_original
      Added value: +{
      +  "description": "Whether readers may download the uploaded file itself from the page. Applies to a Word, PowerPoint or Excel file only, and is off by default for them, because the file holds what the page does not show: speaker notes, hidden slides, sheets, rows and columns, formulas, comments and tracked changes. Pass true to offer it anyway; on update_site, leave it out to keep the live version's choice. A macro-enabled .docm, .pptm or .xlsm is never offered. A CSV, image, video, audio, PDF, diagram or text file is its page and always downloads; a Markdown file or notebook becomes its page and has no download. The result reports `original_included`, and `render_notices` says what the page could not show (cells shown as formulas when a workbook carries no computed values; a file left out for size). Relay a notice to the user.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / upload_id / description
      Previous value: -"Reference a bundle already uploaded via create_bundle_upload (sent with upload_bundle_part, or PUT to its `upload_url`); use this for a large or multi-file app (e.g. a built React site) that exceeds the inline `html`/`zipBase64` limit. Mutually exclusive with `html` and `zipBase64`."New value: +"Reference a bundle already uploaded via create_bundle_upload (sent with upload_bundle_part, or PUT to its `upload_url`); use this for a large or multi-file app (e.g. a built React site) that exceeds the inline `html`/`zipBase64` limit, or for a single file that is not a zip (Markdown, a notebook, a PDF, an image, a video, an audio, a CSV, a Mermaid diagram or a text file), sent as it is together with `filename`. Mutually exclusive with `html` and `zipBase64`."
    • changedInput schema / properties / zipBase64 / description
      Previous value: -"Base64-encoded .zip bundle (entry HTML + assets), for a multi-file bundle small enough to inline. A single HTML document belongs in `html` instead: base64 has to be reproduced byte for byte and a long string often is not, so this input is rejected outright if the encoding or the archive checksums do not verify."New value: +"Base64-encoded .zip bundle (entry HTML + assets), for a multi-file bundle small enough to inline; a .docx, .pptx or .xlsx (zips themselves) or a one-entry zip holding a single Markdown, notebook, PDF, CSV, image, video, audio, Mermaid or text file under its real name also goes here. A single HTML document belongs in `html` instead: base64 has to be reproduced byte for byte and a long string often is not, so this input is rejected outright if the encoding or the archive checksums do not verify."
  4. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Optional: the workspace (the personal space or a Pro workspace) to act in, from list_workspaces. Omit to act in the token owner's own account."New value: +"Optional: the workspace to act in, from list_workspaces (the connection reaches the person's personal space and every workspace they are a member of). Required on a write when the connection reaches more than one workspace. Omit to act in the personal space (for an older single-workspace connection, the one workspace it was authorized for)."
  5. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing what is preserved (URL, visibility, allowlist, link expiry, view password), that a new version is recorded, refresh behavior for open viewers, security-policy scanning of external references, missing-file reporting, and the warning when html replaces a file-rendered site. Idempotency and non-destructiveness are consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and dense; the final two sentences about collection setup, external origins, and missing files are useful but buried and verbose. Front-loading the user triggers is good, but the run-on structure hurts scannability.

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 mutation tool with no output schema, the description covers behavioral consequences, preservation guarantees, and failure/reporting paths thoroughly. It doesn't explain the return structure, but the description already references result fields (content_kind, original_included, render_notices) which compensates.

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

Parameters5/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, but the description adds real value: it summarizes the accepted content kinds, notes that filename is for lone non-zip files, explains include_original behavior on update ('leave it out to keep the live version's choice'), and describes content_kind changes. This is meaningfully beyond the schema.

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 opens with explicit user-intent triggers ('push the new version', 'ship the changes', 'update the page while keeping the same link') and states the core mechanic: 'Replaces a site's content in place by id.' It clearly distinguishes itself from publish_site by emphasizing URL preservation and in-place replacement.

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 opening sentence gives clear when-to-use triggers phrased in user language, and it repeatedly anchors 'same inputs as publish_site', implicitly the alternative. It doesn't explicitly state when NOT to use it (e.g., first-time publishing), but the context is clear.

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.