Skip to main content
Glama
Sign In
WebCake Storefront MCP

WebCake Storefront MCP

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_global_source_elements

Batch update multiple elements in a global source: preview per-element diffs with dry_run=true, get user confirmation, then apply with dry_run=false.

Instructions

Batch update multiple elements in one global source. Two-step process: STEP 1: Call with dry_run=true (default) → returns per-element diff. STEP 2: Show all diffs 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. Same merge rules: style/config/specials = shallow merge, events/bindings = replace.

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": {
      "global_source_id": "<global_source_id>",
      "updates": "<updates>"
    },
    "name": "update_global_source_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNoPreview only (true) or apply changes (false). Defaults to confirm_mode setting.
updatesYesArray of element updates
componentNoComponent hint for faster lookup
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.
global_source_idYesGlobal source ID

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.7/5.0
Behavior5/5

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

Beyond the readOnlyHint=false annotation, the description explains the preview/apply behavior, mandatory user confirmation, and data-loss risk. It also documents merge semantics: shallow merge for style/config/specials and replace for events/bindings.

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 and structured with STEP markers and an IMPORTANT warning, which makes the safety workflow easy to follow. The confirmation requirement is repeated in consecutive sentences, which adds emphasis but also some redundancy.

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 high-risk batch mutation tool with no output schema, it covers the critical safety workflow, preview return behavior, and merge rules. It is slightly incomplete regarding partial-failure handling and the actual dry_run default when confirm_mode is configured differently.

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 schema already documents all five parameters. The description adds meaningful semantics for the nested update fields with its shallow-merge versus replace rules, though it does not clarify component or allow_shrink and its statement that dry_run defaults to true conflicts with the schema's 'confirm_mode setting' note.

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 description states a specific verb and resource: batch update multiple elements in one global source. The word 'batch' and 'multiple elements' distinguish it from the singular update_global_source_element sibling, so an agent can identify its role 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit three-step workflow: preview with dry_run=true, show diffs for user confirmation, then apply with dry_run=false. It also states a hard exclusion ('NEVER proceed without explicit user approval'), leaving little ambiguity about when and how to use it.

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