Skip to main content
Glama
vuluu2k

WebCake Landing MCP

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_page

Destructive

Replaces an existing page's stored source with an edited tree (source only; the published build is not refreshed). Validates first.

Instructions

Replaces an existing page's stored source with an edited tree (source only; the published build is not refreshed). Validates first. Concurrency check: the save is refused with page_changed_externally when the page was edited elsewhere since it was last read (base_version, or the version the server recorded), or with unverified_overwrite when an unverified save would delete live element ids; force:true overrides. dry_run defaults to true: it validates, caches the source under a draft_id and returns the masked request; dry_run:false saves. A draft_id from a dry run or a failed/timed-out update re-runs from the cached source. Requires Webcake credentials.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoDefault false. true saves even when the page changed outside this session, discarding those outside changes.
sourceNoThe edited page source { page, popup, settings, options, cartConfigs } (object or JSON string). Required unless draft_id is given. The compacted tree from get_page can be edited and sent back AS-IS — sparse nodes are re-hydrated from factory defaults (a full tree also works).
dry_runNoDefault TRUE — validate, cache the source as draft_id, and preview without sending. Set false to actually save.
page_idNoThe page id to update (must be owned by the account). Required unless draft_id is given (the page_id is stored in the draft).
draft_idNoA draft_id from a previous update_page call (dry_run=true or a timed-out/failed update). Loads the cached source, so the full JSON is not re-sent; covers the dry-run → real call step and retries after a timeout.
base_versionNoThe page's source_version as returned by get_page. When it no longer matches the live page, the save is rejected rather than reverting edits made in the Webcake editor meanwhile. Optional — when omitted, the server uses the version it recorded at this session's last read or write of the page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.11
    • changedInput schema / properties / base_version / description
      Previous value: -"The source_version get_page returned for this page. When it no longer matches the live page the save is REJECTED instead of reverting whatever was edited in the Webcake editor meanwhile. Optional — omit it and the server uses the version it recorded on your last read/write of this page."New value: +"The page's source_version as returned by get_page. When it no longer matches the live page, the save is rejected rather than reverting edits made in the Webcake editor meanwhile. Optional — when omitted, the server uses the version it recorded at this session's last read or write of the page."
    • changedInput schema / properties / draft_id / description
      Previous value: -"A draft_id from a previous update_page call (dry_run=true or a timed-out/failed update). Loads the cached source — no need to re-send the full JSON. Use for dry-run → real call transitions and retrying after a timeout."New value: +"A draft_id from a previous update_page call (dry_run=true or a timed-out/failed update). Loads the cached source, so the full JSON is not re-sent; covers the dry-run → real call step and retries after a timeout."
    • changedInput schema / properties / force / description
      Previous value: -"Default false. true = save even when the page changed outside this session, discarding those changes. Only pass it after the user has said to."New value: +"Default false. true saves even when the page changed outside this session, discarding those outside changes."
    • addedInput schema / properties / source / anyOf
      Added value: +[
+  {
+    "additionalProperties": {},
+    "type": "object"
+  },
+  {
+    "type": "string"
+  }
+]
  2. Changed2 schema fields changedv1.5.2
    • addedInput schema / properties / base_version
      Added value: +{
+  "description": "The source_version get_page returned for this page. When it no longer matches the live page the save is REJECTED instead of reverting whatever was edited in the Webcake editor meanwhile. Optional — omit it and the server uses the version it recorded on your last read/write of this page.",
+  "type": "string"
+}
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Default false. true = save even when the page changed outside this session, discarding those changes. Only pass it after the user has said to.",
+  "type": "boolean"
+}
  3. First observedv1.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true, but the description goes well beyond them: it discloses the validate-first step, the exact refusal codes (page_changed_externally, unverified_overwrite), the force:true override, the dry_run default and draft caching, and the Webcake credential requirement. An agent knows what gets destroyed (outside edits on force) and what failure modes to expect.

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-loads the core behavior, then layers validation, concurrency, dry-run, draft reuse, and credentials — every sentence carries distinct information with no filler. It is dense and would read better with minor structure, but nothing is redundant.

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?

With no output schema, the description still explains what a dry run returns (a masked request + draft_id) and the reuse path, plus failure behavior and auth requirements. For a destructive 6-parameter mutation tool, nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so the baseline is 3 and the per-parameter docs already carry the load. The description still adds integration value by wiring the parameters into a workflow — how base_version/force interact in the concurrency check, and that draft_id lets a retry re-run from cached source without resending JSON — rather than merely restating individual 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?

Opens with a specific verb+resource and scope: 'Replaces an existing page's stored source with an edited tree (source only; the published build is not refreshed).' The parenthetical implicitly separates it from publish_page and patch_page by nailing down that only the stored source changes, which lets an agent route correctly without opening schemas.

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 strong when-to-use context: validate-first flow, dry_run defaulting to true, draft_id reuse after a dry run or timeout, and when the server refuses the save. It never names a sibling alternative (e.g. patch_page vs update_page, or publish_page for the live build) explicitly, so it falls just short of a 5.

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

Deploy Server

Other Tools