Skip to main content
Glama
vuluu2k

WebCake Storefront MCP

by vuluu2k

get_global_source_detail

Read-only

Retrieve a global source's compact tree view, listing each element's ID, type, text, class, events, bindings, and child count. Add a component hint for faster lookup.

Instructions

Get full detail of a global source — compact tree view showing all elements. Each line: ID [type] "text" .class [events] [bindings] (children_count). Provide component for faster lookup; omit if you already called list_global_sources.

Input Schema

NameRequiredDescriptionDefault
componentNoComponent hint for faster lookup (e.g. "popup", "cart-droppable")
global_source_idYesGlobal source ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.31.8

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description goes beyond that by disclosing the exact return format ("ID [type] text .class [events] [bindings] (children_count)"), which is valuable since there is no output schema. It still does not mention size limits or pagination.

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?

Three sentences, front-loaded with the purpose before the output-format details. The dense line-format string earns its place by describing the return shape, though it is harder to parse than a short prose summary.

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?

With no output schema, the description carries the return-value burden and does so by explaining the tree line format; annotations cover safety and the schema covers both params. An agent has enough to call it correctly, though the relationship to get_global_source_contents remains unaddressed.

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?

Schema coverage is 100% and the schema description already explains the component hint, so the baseline is 3. The description adds the marginal insight that component can be omitted after calling list_global_sources, but does not enrich global_source_id beyond the schema.

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 ("Get full detail of a global source") and even describes the output shape (compact tree view of all elements). It does not differentiate from the close sibling get_global_source_contents, which sounds like it could return similar detail, so sibling differentiation is incomplete.

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

Usage Guidelines3/5

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

"Provide component for faster lookup; omit if you already called list_global_sources" gives one actionable condition tied to a sibling, but it is guidance about a parameter rather than when to choose this tool over alternatives like get_global_source_contents. Usage is implied rather than explicitly scoped.

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