Skip to main content
Glama
vuluu2k

WebCake Storefront MCP

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_page_element

Updates properties of a page element, including styles, config, events, or responsive overrides; previews a diff before applying user-confirmed changes.

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 }).

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: {...}}})

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.31.8

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, so the description carries the real load and does so richly: per-field merge semantics (shallow for style/config/specials, by bp key for responsive), full REPLACE for events/bindings, auto-normalization of entries, dry_run defaulting to the confirm_mode setting, and an explicit data-loss warning. This is exactly the behavioral context annotations cannot supply.

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 workflow and broken into labeled steps, but steps 2 and 3 plus the follow-up IMPORTANT sentence restate the same confirmation requirement three times. Slightly redundant, though the merge-rules block is dense and earns its space.

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 9-parameter mutation tool with no output schema and near-empty annotations, the description covers the critical path: preview semantics, confirmation gate, and merge behavior, and it notes dry_run returns a diff. It leaves the apply-path response shape unspecified, a minor gap given no output schema.

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?

Schema coverage is already 100%, but the description adds meaning the schema does not: which fields merge vs replace, that events/bindings require the COMPLETE array, and that dry_run defaults from the confirm_mode setting (toggle_confirm_mode changes it). This is additive rather than redundant.

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: 'Update properties of a specific element in page source.' The singular 'a specific element' distinguishes it from the plural sibling update_page_elements and the coarser update_page_source. An agent can select it without opening the schema.

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?

Provides an explicit three-step workflow (dry_run preview, user confirmation, apply) and names get_page_element as the read-first companion for events/bindings. However, it never states when to prefer this over siblings like update_page_elements or update_page_source, so the routing decision is left implicit.

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