Skip to main content
Glama
VenticinqueMauro

Shopify Insights MCP

get_customer_segments

Identify customer segments by order history and spending to tailor marketing strategies. Shows distribution and average spend per segment, revealing VIP, Loyal, Returning, New, and Inactive groups.

Instructions

Segment customers into VIP, Loyal, Returning, New, and Inactive based on order history and spending. Shows distribution and average spend per segment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodNoPeriod to determine activity (default: month)month
endDateNoEnd date (only for custom period)
startDateNoStart date (only for custom period)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must disclose behavior itself. It does state the analytical output (distribution and average spend per segment) and implies a read-only reporting operation, but it does not explain segment thresholds, period semantics beyond the schema, or any side effects. This is adequate but not rich.

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?

Two sentences, no filler, with the core purpose front-loaded and the output summarized immediately. The segment list is compact yet informative.

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 report-style tool with no required parameters, the description names the returned aggregate outputs (distribution and average spend) and the schema documents the optional parameters. It does not specify exact output structure or segment-rule thresholds, but an agent has enough to invoke it correctly.

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%, with all three parameters (period, endDate, startDate) already described, including the period enum and default. The description adds no parameter-specific meaning, so the baseline of 3 is appropriate.

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?

The description names a specific action (segment), a clear resource (customers), and enumerates the resulting segment types (VIP, Loyal, Returning, New, Inactive) along with the basis (order history and spending). This clearly distinguishes it from sibling analytics tools such as get_revenue_breakdown or get_inventory_alerts.

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

Usage Guidelines4/5

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

The description makes the tool's context clear: an agent should use it when customer segmentation by purchasing behavior is needed and to see segment distribution and average spend. It does not explicitly contrast with get_top_customers or state when not to use it, but the purpose is specific enough to imply correct routing.

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