WebCake Landing MCP

publish_page

Destructive

Instructions

Publishes an existing page: builds the rendered app on the Webcake build host (POST /render/build; https://build.webcake.io in production, overridable with WEBCAKE_BUILD_BASE / x-webcake-build-base) and then creates or updates the published record that public serving reads. With custom_domain (already pointed at Webcake) the page is served at that domain; when omitted, the page's currently attached domain is reused; with no domain, or custom_domain:'', only the preview link (/preview/<page_id>) is returned, and it renders for about 10 minutes after the publish. Without a build host, or if the build fails, it falls back to a source-only publish that saves a version but serves nothing, and returns a warning. dry_run defaults to true and makes no network calls; dry_run:false builds and publishes. Requires Webcake credentials.

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": {
      "page_id": "<page_id>"
    },
    "name": "publish_page"
  }
}

Input Schema

Name	Required	Description
`dry_run`	No	Default TRUE — preview the request without sending. Does NOT call the build host. Set false to actually publish (build + publish).
`page_id`	Yes	The page id to publish (must be owned by the account).
`custom_path`	No	Optional path under the custom domain (e.g. 'sale').
`custom_domain`	No	Optional custom domain to serve the page at (e.g. 'shop.example.com' — must already point at Webcake). Use it EXACTLY as the account lists it: 'www.example.com' and 'example.com' are DIFFERENT domain records — a www/non-www mismatch is corrected to the stored form, and a domain the account never added is refused (nothing published). OMIT to reuse the page's CURRENTLY-ATTACHED domain (so republishing keeps it live at the same URL, like the editor's publish modal); if the page has none it publishes domain-less (preview-host URL). Pass an empty string '' to force a domain-less publish even when the page has a domain.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.1Oct 22, 2026

changedInput schema / properties / custom_domain / description

Previous value: -"Optional custom domain to serve the page at (e.g. 'shop.example.com' — must already point at Webcake). OMIT to reuse the page's CURRENTLY-ATTACHED domain (so republishing keeps it live at the same URL, like the editor's publish modal); if the page has none it publishes domain-less (preview-host URL). Pass an empty string '' to force a domain-less publish even when the page has a domain."New value: +"Optional custom domain to serve the page at (e.g. 'shop.example.com' — must already point at Webcake). Use it EXACTLY as the account lists it: 'www.example.com' and 'example.com' are DIFFERENT domain records — a www/non-www mismatch is corrected to the stored form, and a domain the account never added is refused (nothing published). OMIT to reuse the page's CURRENTLY-ATTACHED domain (so republishing keeps it live at the same URL, like the editor's publish modal); if the page has none it publishes domain-less (preview-host URL). Pass an empty string '' to force a domain-less publish even when the page has a domain."

First observedv1.5.0Jul 30, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: build host endpoint, credential requirement, fallback source-only publish that serves nothing and returns a warning, and preview link lifetime of about 10 minutes. These details are important for a destructive, open-world publish operation and do not contradict the destructiveHint annotation.

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 purpose is front-loaded in the first clause, but the description is a dense single paragraph with heavy parenthetical detail. It is information-rich rather than concise, and some domain behavior overlaps with the schema.

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?

Covers key edge cases for a complex publish operation: build-host fallback, missing credentials, domain reuse, forced domain-less publishing, and dry_run behavior. It does not describe the success return shape, and there is no output schema, but the invocation-critical context is largely present.

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 description coverage is 100%, so the schema already documents all four parameters. The description reinforces custom_domain and dry_run semantics, but custom_path is never mentioned and much of the custom_domain explanation repeats the schema, so it adds only modest value beyond structured fields.

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?

States a specific verb and resource: publishing an existing page, then building the rendered app and creating/updating the published record. This clearly distinguishes it from sibling tools like render_preview, validate_page, and update_page.

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?

Gives clear context for invocation, including dry_run defaulting to true, custom_domain reuse/override behavior, and the no-domain preview fallback. It does not explicitly compare against sibling tools such as render_preview or validate_page, so it stops short of full when/when-not guidance.

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