Skip to main content
Glama
Sign In
WebCake Storefront MCP

WebCake Storefront MCP

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_page_element

Preview and apply changes to a page element's styles, config, text, events, and responsive overrides, returning a diff for user confirmation before saving.

Instructions

Update properties of a specific element in page source. Two-step process: STEP 1: Call with dry_run=true (default) → returns diff of what will change. STEP 2: Show the diff to the user and ask for confirmation. NEVER proceed without explicit user approval. STEP 3: Only after user confirms, call again with dry_run=false to apply. IMPORTANT: You MUST show the diff to the user and get explicit "yes/ok/confirm" before calling with dry_run=false. Skipping confirmation risks data loss. Merge rules: style/config/specials = shallow merge, responsive = merge by bp key. events/bindings = REPLACE the whole array — pass the COMPLETE list (read it first with get_page_element so you don't drop the others); entries are auto-normalized (id + eventName filled in, so you can pass just { action, ...fields } / { target }).

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>",
      "element_id": "<element_id>"
    },
    "name": "update_page_element"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleNoCSS style properties to merge (e.g. {color: '#fff', 'font-size': '16px'})
configNoConfig properties to merge
eventsNoComplete events array (replaces existing)
dry_runNoPreview only (true) or apply changes (false). Defaults to confirm_mode setting. Use toggle_confirm_mode to change default.
page_idYesPage ID
bindingsNoComplete bindings array (replaces existing)
specialsNoSpecials to merge (text, custom_class, custom_css, etc.)
element_idYesElement ID to update (e.g. 'TEXT-3', 'BUTTON-1')
responsiveNoResponsive breakpoint overrides (e.g. {bp1: {style: {...}, config: {...}}})
allow_shrinkNoAllow the source to shrink by more than half: set it when native elements replaced an oversized embed or custom_css and you have read it first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.38.0
    • addedInput schema / properties / allow_shrink
      Added value: +{
+  "description": "Allow the source to shrink by more than half: set it when native elements replaced an oversized embed or custom_css and you have read it first.",
+  "type": "boolean"
+}
  2. First observedv1.31.8

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only supply readOnlyHint=false, so the description carries the rest and does so well: it discloses the mandatory confirmation gate, the data-loss risk of skipping it, per-field merge semantics (shallow merge for style/config/specials, breakpoint-keyed merge for responsive, full REPLACE for events/bindings), auto-normalization of entries, and when allow_shrink is safe.

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 purpose, then numbered steps, then merge rules as a distinct block — easy to scan. It is dense with emphasis markers and repeats the confirmation requirement twice, but the repetition is a deliberate safety emphasis rather than filler.

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 10-parameter mutation with nested objects and no output schema, the description covers everything an agent needs: safety workflow, destructive-merge hazards, the prerequisite read, and normalization conveniences. The diff return value of the dry run is described, compensating for the absent output schema.

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 100%, so the baseline is 3; the description goes beyond the schema descriptions by explaining that events/bindings replace the whole array and require the complete list, that style/config/specials shallow-merge, that responsive merges by breakpoint key, and that event/binding entries are auto-normalized so minimal objects are accepted. Only allow_shrink's exact failure condition and the confirm_mode default resolution are left slightly implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Update properties of a specific element in page source,' which clearly separates it from update_page_source (whole source) and update_page_elements (plural/bulk). It never names those siblings explicitly, so the agent must infer the distinction, but the singular 'a specific element' plus the required element_id makes the scope unambiguous.

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?

Gives an explicit workflow: call with dry_run=true first, show the diff and get approval, then call with dry_run=false. It also names the alternative read path ('read it first with get_page_element') for the array-replacement case and warns against skipping confirmation, leaving nothing to inference.

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