Skip to main content
Glama

Publish one page or document (no terminal)

publish_file

Publish an HTML / Markdown page or document straight to a WeChat-ready LivePage link; no terminal needed. Which upload route: terminal ⇒ SPACE CLI (create_cli_token first); no terminal and text files up to 2 MB in total ⇒ publish_file; anything else or unsure ⇒ create_upload_link. The link opens and forwards inside WeChat (links from WorkBuddy's built-in site publishing, *.app.workbuddy.host, cannot be opened inside WeChat); use this when the user wants it in WeChat. Use this when you have no terminal and the page is text files — HTML or Markdown pages and documents (no upload session to open first): pass the complete text content and the platform uploads it for you. Validation, content moderation (never released while moderation is unavailable), automatic release after approval or hold, and the result are exactly the same as finalize_upload. To add a version to existing pages pass proposal_id (find it with list_proposals first); to create new pages pass title (optional folder_id). One file: pass filename + content (.html / .htm / .md). When the page, styles and scripts are separate files, pass files: [{ path, content }] instead (one or the other): paths may include directories (e.g. css/style.css) and pages reference each other with relative paths; text files only (html / htm / md / css / js / mjs / json / svg / txt / csv), at most 50; the entry is manifest.entry, else index.html, else the only page. When a file is already at a public https URL (a cloud-drive public download link, a PDF link produced by another tool), pass { path, url } in files instead (e.g. [{ path: 'report.pdf', url: 'https://…' }]) and the platform fetches it — PDF, PPTX and images work: up to 50 MB each and 50 MB in total, at most 5 URLs, fetched within 30 seconds; only public addresses, and links that need a login cannot be fetched (fetch_failed, with fetch_* details in issues). UTF-8 text, up to 2 MB in total — anything larger is rejected with too_large and never truncated. The contents of images, PDF, PPTX and other binary files cannot be sent here: use a URL if there is one; otherwise without a terminal, use create_upload_link to give the user an upload page; with a terminal, use the SPACE CLI with create_cli_token. IMPORTANT: when the page already has readers outside the workspace, set hold=true whenever the user has not explicitly approved releasing this version, then give them the preview URL before publish_version. Hold only matters once the page has readers outside the workspace (passcode, public, a folder link or a named link); on a page only workspace members can open — every new page starts that way — hold is ignored and the approved version becomes current directly without notifying anyone. For a small edit (a typo fix) that should not notify anyone, pass quiet=true: workspace people and subscribers are not notified this time, and subscribers are notified on the next update. Keywords: publish · web page · webpage · link · share · share to WeChat · WeChat link · html · pdf · markdown · upload · LivePage · proposal.

Input Schema

NameRequiredDescriptionDefault
tagNoOptional: the tag this version gets when it goes live (a string = the tag name, such as 2026-10-28 / v2 final; or {name, title, note}). On a tagged page readers see the newest tagged version and can browse every tagged one (past issues); an existing tag name moves to this version. Daily reports use the day's date. Omitted: a page that has never been tagged behaves exactly as today; on a tagged page this version takes over the tag readers are looking at
holdNoTrue keeps the approved version waiting to publish until the user confirms; then call publish_version. Default false: approval automatically makes this version live. Only takes effect once the page has readers outside the workspace (passcode, public, a folder link or a named link); on a page only workspace members can open it is ignored, and the approved version becomes current directly without notifying anyone.
noteNoWhat changed this time: one line for subscribers and teammates, 20 characters or fewer, for example “Revised pricing after client feedback”. It appears in the update reminder; without it the reminder only says the version number, and the platform will not make one up.
filesNoA web page made of several files (page, styles, scripts and so on), or files at public URLs; use this or filename / content.
quietNotrue = no notification this time: when this version goes live, neither workspace people nor readers subscribed to this page are notified; subscribers are notified as usual on the next update. Use it for small edits such as typo fixes
titleNoTitle for a new page; with proposal_id it becomes this version’s title.
contentNoFor one file: its complete text content (UTF-8).
filenameNoFor one file: its name, such as index.html or report.md, without a directory; use this or files.
manifestNoOptional manifest fields, the same as finalize_upload (theme / theme_switch / chrome / scene / share / sections / actions …). For one file the entry comes from filename; with files you may set entry to choose the entry page. title defaults to the title above. Page settings can ride along here too (page contract): name (page name) · folder (null = out of any folder) · folder_link (shared through the folder link) · path (workspace address) · forms (same fields as set_form, no amount) · analytics.replay (session recording) · tag; anything left out is untouched, and page_settings in the result reports each item.
folder_idNoOnly when creating a new page: destination folder; omit to keep it out of any folder.
proposal_idNoExisting page to add a version to; supply this or title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / hold / description
      Previous value: -"True keeps the approved version waiting to publish until the user confirms; then call publish_version. Default false: approval automatically makes this version live."New value: +"True keeps the approved version waiting to publish until the user confirms; then call publish_version. Default false: approval automatically makes this version live. Only takes effect once the page has readers outside the workspace (passcode, public, a folder link or a named link); on a page only workspace members can open it is ignored, and the approved version becomes current directly without notifying anyone."
  2. Changed1 schema field changed
    • changedInput schema / properties / manifest / description
      Previous value: -"Optional manifest fields, the same as finalize_upload (theme / theme_switch / chrome / scene / share / sections / actions …). For one file the entry comes from filename; with files you may set entry to choose the entry page. title defaults to the title above."New value: +"Optional manifest fields, the same as finalize_upload (theme / theme_switch / chrome / scene / share / sections / actions …). For one file the entry comes from filename; with files you may set entry to choose the entry page. title defaults to the title above. Page settings can ride along here too (page contract): name (page name) · folder (null = out of any folder) · folder_link (shared through the folder link) · path (workspace address) · forms (same fields as set_form, no amount) · analytics.replay (session recording) · tag; anything left out is untouched, and page_settings in the result reports each item."
  3. Changed1 schema field changed
    • addedInput schema / properties / tag
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maxLength": 40,
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    {
      +      "properties": {
      +        "name": {
      +          "maxLength": 40,
      +          "minLength": 1,
      +          "type": "string"
      +        },
      +        "note": {
      +          "maxLength": 2000,
      +          "type": "string"
      +        },
      +        "title": {
      +          "maxLength": 200,
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "name"
      +      ],
      +      "type": "object"
      +    }
      +  ],
      +  "description": "Optional: the tag this version gets when it goes live (a string = the tag name, such as 2026-10-28 / v2 final; or {name, title, note}). On a tagged page readers see the newest tagged version and can browse every tagged one (past issues); an existing tag name moves to this version. Daily reports use the day's date. Omitted: a page that has never been tagged behaves exactly as today; on a tagged page this version takes over the tag readers are looking at"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / manifest / description
      Previous value: -"Optional manifest fields, the same as finalize_upload (theme / theme_switch / scene / share / sections / actions …). For one file the entry comes from filename; with files you may set entry to choose the entry page. title defaults to the title above."New value: +"Optional manifest fields, the same as finalize_upload (theme / theme_switch / chrome / scene / share / sections / actions …). For one file the entry comes from filename; with files you may set entry to choose the entry page. title defaults to the title above."
  5. Changed2 schema fields changed
    • changedInput schema / properties / note / description
      Previous value: -"Version note, for example: V2, revised pricing after client feedback."New value: +"What changed this time: one line for subscribers and teammates, 20 characters or fewer, for example “Revised pricing after client feedback”. It appears in the update reminder; without it the reminder only says the version number, and the platform will not make one up."
    • addedInput schema / properties / quiet
      Added value: +{
      +  "description": "true = no notification this time: when this version goes live, neither workspace people nor readers subscribed to this page are notified; subscribers are notified as usual on the next update. Use it for small edits such as typo fixes",
      +  "type": "boolean"
      +}
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations' basic mutation profile, it discloses moderation gating, automatic release, hold and notification behavior, remote fetching constraints, and rejection with too_large rather than truncation. The requirement to hold unapproved releases for pages with external readers is especially valuable safety context.

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

Conciseness2/5

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

The purpose and routing are front-loaded, but the remainder is a sprawling, dense paragraph with repeated no-terminal guidance and substantial duplication of the hold, quiet, and file-field schema descriptions. The keyword tail adds further bulk, while headings or bullets would make the many modes and constraints much easier to scan.

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 an 11-parameter, multi-mode publishing tool, it covers selection, invocation combinations, content acquisition, limits, moderation, release safety, notifications, and several errors; the schema documents the remaining fields such as manifest. With no output schema, however, the response contract is only indirectly described as a LivePage link and as being the same as finalize_upload, so the definition is not fully self-contained about the returned result.

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?

Although schema coverage is 100%, the description adds substantial cross-parameter semantics: title versus proposal_id, filename/content versus files, content versus url, and the entry-page fallback order. It also supplies aggregate limits, supported text formats, public-URL restrictions, and concrete failure behavior that the individual schema fields do not fully capture.

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 opening sentence gives a specific action, resource, and outcome: publishing HTML or Markdown content to a WeChat-ready LivePage link without a terminal. It also distinguishes the tool from built-in site publishing and from the CLI and upload-link routes.

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?

It provides an explicit selection tree among SPACE CLI with create_cli_token, publish_file, and create_upload_link, plus separate guidance for WeChat sharing and binary content. It also explains when to use list_proposals for an existing page and when hold leads to preview followed by publish_version.

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.

Resources