Skip to main content
Glama
vuluu2k

WebCake Landing MCP

by vuluu2k

patch_page

Destructive

Fix landing page elements by ID without resending the whole source. Apply updates, replaces, removes, or adds to live pages or cached drafts, then validate and save—the recovery path after failed builds or timeouts.

Instructions

Edits a page by element id WITHOUT re-sending the whole source — the surgical-edit and fix-after-error path. Targets EITHER a live page (page_id) OR a cached draft source (draft_id). Draft sources come from: (a) create_page — failed validation or timed-out network call → patched/committed tree is CREATED as a new page once valid; (b) add_section dry_run or validation/network failure → patched/committed shell is APPENDED to the stored page once valid; (c) update_page or live-page patch_page — timed-out/failed network call → re-committed via updatePageSource. Send only a list of per-element ops; the MCP loads the source, applies them, validates the WHOLE merged tree (blocks on errors), and saves. Ops: {op:'update',id,type?,specials?,styles?:{desktop?,mobile?},config?:{desktop?,mobile?},events?,properties?} (shallow-merges; op defaults to 'update'; type fixes a wrong element type; update CANNOT delete an existing/stray key — schema 'additional properties' errors need op:'replace'), {op:'replace',id,element}, {op:'remove',id}, {op:'add',parent_id,element}. EMPTY/OMITTED patches with a draft_id = commit the cached draft as-is (skip apply, still validate, then honor dry_run) — this is the RETRY PATH after a timeout. Use this to fix the elements a failed create_page/update_page/add_section reported instead of rebuilding. DEFAULTS to dry_run=true (loads + merges + validates + previews, no write); dry_run=false to save. Needs WEBCAKE_API_BASE + WEBCAKE_JWT (a draft_id sections-patch only needs creds to actually append; a page_id patch reads the live page so needs creds even on dry_run).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoDefault false. Only meaningful when committing an 'update' draft: true saves the cached snapshot even though the page changed outside this session, discarding those changes. A page_id patch never needs it — it merges into the tree it just read.
dry_runNoDefault TRUE — load, merge, validate and preview the resulting save WITHOUT writing. Set false to actually save.
page_idNoEdit a LIVE page by id (from create_page, list_pages, or find_pages; must be owned by the account). Provide page_id OR draft_id. For a sections or update draft_id you may also pass page_id here to override the stored page target.
patchesNoOne op object or an array of them (object/array or JSON string). Each targets an element by id: {op:'update',id,type?,specials?,styles?:{desktop?,mobile?},config?:{desktop?,mobile?},events?,properties?} merges fields into the element (op may be omitted; set `type` to fix a wrong element type; update MERGES — it cannot DELETE an existing/stray key, so 'must NOT have additional properties' errors need op:'replace' with a clean node); {op:'replace',id,element} swaps the node; {op:'remove',id} deletes it; {op:'add',parent_id,element} appends a child to a container. `element` may be a SPARSE node (id/type/styles/specials/events only) — the server hydrates omitted boilerplate from factory defaults. OMIT (or pass empty array) when draft_id is given and you just want to commit/retry the cached draft as-is.
draft_idNoCommit or fix a CACHED source: from create_page (failed/timed-out → new page created once valid), add_section (dry_run or failure → sections appended), or update_page/live-page patch (timed-out/failed → updatePageSource retried). The originating tool's error/dry_run response returns draft_id. Provide page_id OR draft_id. Empty/omitted patches = commit the cached draft as-is (the RETRY PATH after a timeout).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv1.5.2
    • addedInput schema / properties / force
      Added value: +{
      +  "description": "Default false. Only meaningful when committing an 'update' draft: true saves the cached snapshot even though the page changed outside this session, discarding those changes. A page_id patch never needs it — it merges into the tree it just read.",
      +  "type": "boolean"
      +}
  2. First observedv1.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the default dry_run=true no-write behavior, that dry_run=false saves, that the whole merged tree is validated and blocks on errors, that update ops shallow-merge and cannot delete stray keys, that empty patches trigger the retry commit path, and that credentials are required differently for draft_id vs page_id. No contradiction with readOnlyHint=false/destructiveHint=true is present.

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?

The description is front-loaded with purpose and every major behavioral rule is packed in without filler. It is quite long and partially duplicates op semantics already present in the schema, so it does not quite reach a perfect conciseness score, but the draft/commit/retry complexity justifies most of the length.

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 complex 5-parameter tool with no output schema, the description covers target selection, draft provenance, op semantics, dry-run default, validation behavior, auth requirements, and retry path. The only gap is that the exact response/preview shape is not described, but everything needed to invoke the tool correctly is covered.

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?

Even though the schema already documents all 5 parameters at 100% coverage, the description adds operational meaning: op defaults to 'update', replace is needed for additional-properties errors, sparse elements are hydrated from factory defaults, omitted patches mean commit-the-cached-draft, and page_id can override the stored target for draft patches. This materially helps an agent build correct argument objects.

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 states a specific verb and resource: 'Edits a page by element id WITHOUT re-sending the whole source', and immediately distinguishes it from a whole-source update path. It also clarifies the two target kinds (live page vs cached draft), so an agent can tell this tool apart from update_page and sibling create/edit tools.

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?

The description explicitly positions this as the fix-after-error and retry path: 'Use this to fix the elements a failed create_page/update_page/add_section reported instead of rebuilding.' It also explains when to commit a cached draft as-is with empty patches, when dry_run should be set, and when page_id vs draft_id apply. This is strong usage guidance with clear alternatives.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vuluu2k/webcake-landing-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server