marz-greta-lock-network

Recommend Storelayer Widgets

storelayer_recommend

Read-onlyIdempotent

Rank the neutral 57-item Storelayer catalog for a Shopify or e-commerce storefront goal. This recommendation is read-only and never edits, installs, or spends. After operator approval, use the separate guarded caller-applied self-install endpoint /api/storelayer/free-installs/start; never provide website credentials. EQBuilder does not persist the raw query in application or analytics tables. Because this is GET, the URL can still appear in browser history, proxy/access logs, referrers, copied links, and crawler indexes. Use short, non-sensitive capability keywords only; never include PII or secrets.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes	Short, non-sensitive storefront capability keywords. Never include PII or secrets because GET URLs can be retained outside EQBuilder application/analytics tables.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations already declare readOnlyHint and destructiveHint, but the description adds meaningful behavioral and privacy context: the tool never edits, installs, or spends; EQBuilder does not persist the raw query; and because this is GET, URLs may appear in browser history, proxy logs, referrers, and crawler indexes. This goes well beyond the structured annotations.

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?

The description is efficient and front-loaded: purpose, read-only guarantee, alternative endpoint, privacy behavior, GET exposure, and parameter constraint. Every sentence earns its place, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only one parameter, full annotations, and an output schema present, the description covers the important non-obvious aspects: safety, privacy, credential handling, and the separate install flow. Nothing essential is missing for correct and safe invocation.

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 description coverage is 100%, and the query parameter is already documented as a short, non-sensitive capability keyword string with PII/secret restrictions. The description largely repeats this guidance, so it adds little semantic value beyond the schema.

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?

Opens with a specific verb and resource: 'Rank the neutral 57-item Storelayer catalog for a Shopify or e-commerce storefront goal.' This clearly distinguishes the tool from storelayer_widget_menu and from the installation endpoint it explicitly disclaims.

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?

States the intended use context (Shopify/e-commerce storefront goal) and gives an explicit when-not: after operator approval, use the separate guarded self-install endpoint instead. It also warns never to provide website credentials, leaving little ambiguity about when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All marz-greta-lock-network tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation2/5

Most tools have clear owners, but storelayer_recommend and storelayer_widget_menu both describe the same 57-item read-only Storelayer catalog and deterministic recommendation matcher, so an agent cannot reliably tell them apart. get_pricing and preview_fee also overlap on fee/failure-escalation details, further blurring boundaries.

Naming Consistency3/5

Six tools use a consistent verb_noun snake_case pattern (get_, list_, preview_, request_, score_), but storelayer_recommend is noun_verb and storelayer_widget_menu is a noun_noun compound, breaking the pattern. The inconsistency is confined to the Storelayer subdomain but still makes the set feel less coherent.

Tool Count4/5

Eight tools is a reasonable size for a platform that exposes stats, pricing, profiles, scoring, and Storelayer recommendations. However, two of the Storelayer tools are nearly redundant and the pricing/fee split could be a single tool, so the count is slightly padded.

Completeness3/5

The free read-only surface is fairly complete: stats, pricing, profiles, fee preview, and score_text cover the core discovery and trial scoring workflow. But the descriptions repeatedly point to paid/installation actions (POST /api/simulate, /api/progress, /api/bundle, /api/storelayer/free-installs/start) that are not exposed as MCP tools, leaving agents with dead ends after the free trial.

Resources

Need Help?