Skip to main content
Glama
Sign In
WebCake Storefront MCP

WebCake Storefront MCP

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_global_source

Replaces global source's full configuration after review and confirmation, with safeguard against unintended size reductions. Use for complete rewrites; prefer element-level edits for smaller changes.

Instructions

Replace full source of a global source. IMPORTANT: Before calling this tool, you MUST:

  1. Read existing source with get_global_source_detail first

  2. Show the user what will change and get explicit confirmation

  3. NEVER call without user approval — this replaces the ENTIRE source Safeguarded: blocks if new source is <50% of existing size. For element-level changes, prefer update_global_source_element instead.

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

Input Schema

NameRequiredDescriptionDefault
sourceNoNew source configuration (JSON object)
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?

The lone annotation (readOnlyHint=false) says only that this writes; the description carries the real behavioral weight: it destroys the ENTIRE source, requires user approval, and is guarded by a <50% shrink block. It even explains how to legitimately bypass that guard via allow_shrink after reading — behaviour an agent could not infer from the schema or annotations.

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 destructive operation, then a numbered mandatory checklist, then the safeguard and alternative. Every line carries information, though the caps-lock warnings and the 'IMPORTANT' preamble add some visual bulk that a tighter phrasing could absorb.

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 3-parameter, no-output-schema mutation tool this covers the critical unknowns: destructiveness, approval requirement, shrink guard, and the better sibling for partial edits. Return value shape is unspecified, which is a minor gap for an agent wanting to confirm success without a follow-up read.

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 baseline is 3; the description earns an extra point by explaining the mechanism behind allow_shrink (the 50% size guard) and what the source field stands for (full configuration, not a patch). It doesn't add format or shape details for the source JSON beyond the schema's 'JSON object'.

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 ('Replace full source of a global source') and immediately distinguishes itself from the sibling that does partial work ('For element-level changes, prefer update_global_source_element instead'). An agent can tell this apart from update_global_source_element(s) and update_global_source_contents without opening any 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?

Gives an explicit prerequisite sequence (read via get_global_source_detail first, show the user, get explicit confirmation) plus a clear routing rule to the element-level alternative. Both when-to-use and when-not-to-use are stated rather than implied.

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