Skip to main content
Glama
Sign In
WebCake Storefront MCP

WebCake Storefront MCP

by vuluu2k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

delete_global_source

Destructive

Delete a global source and its published version by providing the global source ID. This removes both the source and its live version from the WebCake storefront.

Instructions

Delete a global source and its published version

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": "delete_global_source"
  }
}

Input Schema

NameRequiredDescriptionDefault
global_source_idYesGlobal source ID to delete

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.31.8

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description contributes one genuinely useful behavioral fact beyond that: deletion cascades to the published version. It stops short of stating irreversibility or any permission requirement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single nine-word sentence with the destructive verb front-loaded and no filler. Nothing could be removed without losing meaning.

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 one-parameter destructive tool with annotations carrying the safety profile and no output schema to explain, the description covers the essential cascade effect. What remains missing is modest: irreversibility/recovery and whether the target must be in a particular state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema coverage is 100%, so the schema fully documents global_source_id. The description adds no format, naming, or ID-sourcing detail beyond what the schema already says, which is the baseline case for a fully documented single parameter.

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 (Delete) plus resource (global source) and adds scope detail that the resource's published version goes with it. This distinguishes it from get_global_source_detail / update_global_source, though it never explicitly contrasts with the similarly named delete_global_section sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites (e.g., must the source be unpublished first?), and no reference to alternatives such as unpublishing/updating instead. The agent must infer the occasion entirely from the tool name.

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