Skip to main content
Glama

Publish site

publish_site

Use when the user wants to put a page online, share this with a client or teammate, or get a link they can send. Publishes a document or bundle to SnapHost and returns its stable share URL. Provide either html (one document) or zipBase64 (a full bundle, a .docx/.pptx/.xlsx, or a one-entry zip holding one Markdown, .ipynb, PDF, CSV, image, video, audio, Mermaid or code file, or a .tsx/.jsx React component); a lone non-zip file goes through create_bundle_upload with filename. Each renders to a sandboxed site that never shows notes, hidden slides, sheets, rows or columns, or comments; an Office file downloads only with include_original; render_notices says what the page could not show. The content kind is detected on publish and returned as content_kind. Pass a slug to make the publish idempotent: the first call creates the site, later calls with the same slug update it at the same URL. Optionally set status (draft hides it until published) and an allowlist (Pro only). The result reports link_expires_at and has_view_password; manage them with set_link_expiry / set_view_password / clear_view_password. A new site lands in the publisher's own My drive, addressed on the workspace subdomain as /~/, unless folder_id (from list_folders) or space "shared" files it on the Shared drive, where it is addressed by its slug or folder path (a slug is looked up in that place). visibility "public" makes it open to anyone with the link (a landing page must be public). For an app too big to inline, call create_bundle_upload and pass its upload_id instead of html/zipBase64. Publish also scans the page for window.SNAPHOST data usage: a collection the page queries is set up as public_read, one it only appends to stays owner-only, and on the marketing site nothing is opened (the owner asks by name, only for records with no personal detail); the result reports what was configured; relay it and confirm with the owner. The page is also scanned for external references (CDN scripts, font stylesheets, embeds) that the site's security policy will block: the result lists each blocked origin. Ask the owner whether to trust it (add_external_origins) or vendor the asset into the bundle. Relative references to files missing from the upload are reported too; include those files and republish. Reports, decks, dashboards: pass document_kind.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlNoA single self-contained HTML document
slugNoSlug, unique within the drive the site is filed in; reuse it with the same folder_id or space to update the same site at the same URL. For a landing page the slug IS the address under /lp: pass exactly the path you were asked for; omitted, it is derived from the title and the page lands at a different address. A slug already used by a site elsewhere on the drive is refused.
spaceNoDrive root for a folderless site: `personal` (default, the publisher’s My drive) or `shared`. Ignored when folder_id is given.
titleYesTitle shown to the owner in the dashboard
statusNo`published` (default) is live immediately; `draft` stays hidden until published
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.
allowlistNoEmails or domains allowed to view a private site (Pro only)
folder_idNoFile the new site into this folder (folder_id from list_folders). A landing page goes into the website workspace’s Marketing folder: pass that workspace’s workspace_id as well; without it the publish is refused on a connection that reaches several workspaces (and lands in the personal space on one that reaches only it), and the site is not a landing page, whatever its slug.
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.
visibilityNo`public`: anyone with the link (the default on Free). `allowlist` (the default on Pro): only the people on the allowlist, after verifying their email; Free may name up to 3. A landing page must be public. Applies to a NEW site only; change an existing site with set_visibility.
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. Changed2 schema fields changed
    • changedInput schema / properties / folder_id / description
      Previous value: -"File the new site into this folder (folder_id from list_folders). A landing page goes into the website workspace’s Marketing folder: pass that workspace’s workspace_id as well; without it the site lands in your own account and is not a landing page, whatever its slug."New value: +"File the new site into this folder (folder_id from list_folders). A landing page goes into the website workspace’s Marketing folder: pass that workspace’s workspace_id as well; without it the publish is refused on a connection that reaches several workspaces (and lands in the personal space on one that reaches only it), and the site is not a landing page, whatever its slug."
    • 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.8/5.0
Behavior5/5

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

Annotations only give the safety profile (readOnlyHint false, destructiveHint false); the description goes far beyond, disclosing sandboxing, what is suppressed from Office files, that include_original is off by default because notes/hidden slides/comments leak, the window.SNAPHOST data-usage scan, the external-origin security blocking, and the required owner confirmation.

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 use case, then organized roughly input-by-input, and nearly every sentence carries operational content. It is nonetheless a very dense block with some overlap between the prose and the already-verbose schema (slug, filename, include_original are described twice), so it is not maximally tight.

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 a 15-parameter write tool with no output schema, the description still reports return values (content_kind, link_expires_at, has_view_password, original_included, render_notices) and explains all modes of input. An agent has everything needed to call it correctly and to relay results.

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 already 100%, so the baseline is 3, but the description adds cross-parameter and cross-tool meaning: html vs zipBase64 vs upload_id selection, slug idempotency semantics, landing-page slug = address under /lp, and the folder_id/workspace_id coupling. It mostly restates rather than deepens a few fields (allowlist, printable), keeping it out of 5.

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?

Opens with a concrete verb+object ('Publishes a document or bundle to SnapHost and returns its stable share URL') plus the user-facing intent it serves. It is immediately distinguishable from siblings like update_site, create_bundle_upload, and create_share_link without opening any schema.

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?

Explicit triggers ('put a page online, share this with a client or teammate, or get a link they can send') and explicit routing to alternatives: large apps go through create_bundle_upload + upload_id, lone non-zip files via create_bundle_upload with filename, existing sites via update_site, slug for idempotent republish.

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.