Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

shopify_product

Fetch one Shopify product by store URL and handle, returning title, price, availability, options, images, and variant details for product data retrieval.

Instructions

Get Shopify product. Returns one product from any Shopify storefront, given the store URL and the product handle: title, description, product type, tags, price and compare-at price, availability, options, images, and each variant with its own price, availability and barcode. Prices are in decimal currency units; an unknown handle returns 404.

Input Schema

NameRequiredDescriptionDefault
urlYesShopify storefront URL
handleYesProduct handle

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it enumerates the returned fields, states prices are in decimal currency units, and explicitly promises a 404 for an unknown handle. It omits anything about auth, rate limits, or how to obtain a valid handle, which keeps it short of a 5.

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?

Two sentences, front-loaded with the core action, then the payload and error behavior. The long field enumeration is dense but each clause adds information relevant to a single-product fetch; nothing is wasted.

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 properly compensates by listing the returned product and variant fields, plus the price-unit convention and 404 case. The only real gap is not clarifying the handle's form (the storefront URL slug), which matters for a lookup keyed on it.

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% for both parameters, so the schema already defines 'url' and 'handle'. The description repeats both and adds only the framing that the handle identifies one product within a given storefront — marginal value over the structured fields, so the baseline 3 applies.

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 ('Get Shopify product') and immediately scopes it to a single product from any Shopify storefront, which cleanly separates it from the list-oriented sibling shopify_products. An agent knows it is a single-item lookup keyed by store URL plus handle.

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?

The phrase 'from any Shopify storefront' implies the tool works across arbitrary stores, which is useful framing, but there is no explicit when-to-use vs when-not, no mention of shopify_products/search as the alternative for discovery, and no prerequisites for obtaining a handle.

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