Shopify MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific Shopify data domains like sales breakdowns, inventory, orders, customer metrics, and ad spend. There is no overlap in functionality; for example, shopify_sales_by_product focuses on product-level sales while shopify_sales_by_channel handles channel breakdowns, making tool selection straightforward for an agent.
Naming Consistency5/5
All tools follow a consistent 'shopify_' prefix with descriptive snake_case names that clearly indicate their function, such as shopify_inventory and shopify_sales_over_time. This uniform pattern enhances readability and predictability, allowing agents to easily understand and navigate the toolset.
Tool Count5/5
With 13 tools, the server is well-scoped for analytics and reporting in Shopify, covering key areas like sales, inventory, customer behavior, and marketing. Each tool serves a specific, non-redundant purpose, making the count appropriate and efficient for the domain without being overwhelming or insufficient.
Completeness4/5
The toolset provides comprehensive coverage for analytics, including sales, inventory, orders, customer metrics, and ad spend, with a custom query tool for flexibility. Minor gaps exist, such as no direct tools for modifying data (e.g., updating inventory or creating orders), but the custom query can mitigate this, and the focus is clearly on read-only analytics.
Average 3.3/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] sales breakdown' and shows discount-driven revenue, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns paginated results, or what the output format looks like (e.g., list, aggregated data). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: two concise sentences that directly state the tool's purpose and value ('Shows which discounts are driving the most revenue'). There is no wasted text, repetition, or unnecessary elaboration, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, behavioral traits like authentication or rate limits, and usage guidelines compared to siblings. While it states the purpose clearly, it doesn't compensate for the missing structured data, leaving the agent with insufficient context for effective tool selection and 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?
The description adds no parameter-specific information beyond what the input schema provides. With 100% schema description coverage, the schema already documents 'since', 'until', and 'limit' parameters clearly. The description doesn't explain how these parameters affect the sales breakdown (e.g., date filtering logic) or provide additional context, so it meets the baseline of 3 for high schema coverage without adding value.
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?
The description clearly states the tool's purpose: 'Get sales breakdown by discount code' specifies the action (get) and resource (sales breakdown by discount code). It distinguishes from siblings like 'shopify_sales_by_product' or 'shopify_sales_by_channel' by focusing on discount codes. However, it doesn't explicitly contrast with 'shopify_sales_summary' or 'shopify_custom_query', which might offer overlapping functionality, preventing a perfect score.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'Shows which discounts are driving the most revenue,' which implies a use case but doesn't specify prerequisites, exclusions, or compare it to siblings like 'shopify_sales_summary' for high-level metrics or 'shopify_custom_query' for custom analyses. Without such context, the agent must infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for getting data (implying read-only), but doesn't mention authentication needs, rate limits, error handling, or what the output looks like (e.g., format, pagination). For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to clarity, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (data retrieval with parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the output contains (e.g., metrics like revenue, units sold), how results are structured, or any behavioral aspects like data freshness or limitations, leaving the agent with insufficient context for effective use.
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?
The schema description coverage is 100%, with all three parameters ('since', 'until', 'limit') clearly documented in the schema. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without adding extra value.
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?
The description clearly states the tool's purpose as 'Get sales breakdown by country or region,' which specifies the verb ('Get'), resource ('sales breakdown'), and dimension ('by country or region'). It distinguishes from some siblings like 'shopify_sales_by_product' or 'shopify_sales_by_channel' by focusing on geography, but doesn't explicitly differentiate from all sales-related tools.
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?
The description provides no guidance on when to use this tool versus alternatives like 'shopify_sales_summary' or 'shopify_sales_over_time.' It mentions the breakdown dimension (geography) but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what the output format looks like. For a tool with 4 parameters and no output schema, this leaves significant behavioral gaps uncovered.
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 a single, efficient sentence that front-loads the core purpose with specific metric examples. Every word earns its place with no redundant information or unnecessary elaboration. It's appropriately sized for a straightforward data retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address authentication requirements, rate limits, error conditions, or what the return data structure looks like. For a traffic analytics tool that likely returns complex time-series data, more contextual information would be helpful for the agent to use it effectively.
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%, so the schema already documents all 4 parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, default behaviors, or provide usage examples. The baseline of 3 is appropriate when the schema does all the heavy lifting.
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?
The description clearly states the verb 'Get' and the resources 'online store traffic and session metrics' with specific examples like 'visitors, sessions, and conversion rate'. It distinguishes itself from siblings like shopify_sales_by_geography or shopify_inventory by focusing on traffic metrics rather than sales or inventory data. However, it doesn't explicitly contrast with shopify_shop_campaign_insights which might also involve traffic analysis.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to shopify_sales_over_time for revenue trends or shopify_customer_metrics for customer behavior. There are no prerequisites, exclusions, or explicit alternatives named in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'shows spend per event for a date range,' which implies a read-only operation, but doesn't clarify permissions, rate limits, data freshness, or what happens with invalid dates. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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 extremely concise and front-loaded: two sentences that directly state the tool's function and scope without any fluff. Every word earns its place, making it easy for an agent to quickly grasp the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and scope but lacks details on behavioral traits, output format, or error handling. Without annotations or output schema, the agent must infer these aspects, leaving room for uncertainty in 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?
The schema description coverage is 100%, with both parameters (since, until) well-documented in the schema regarding format and defaults. The description adds minimal value beyond the schema by mentioning 'date range' but doesn't provide additional context like timezone handling or event filtering. Baseline 3 is appropriate since the schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Get ad spend from Shopify marketing events' with specific resources (Shop campaigns) and scope (per event for a date range). It distinguishes itself from siblings like shopify_sales_by_channel or shopify_shop_campaign_insights by focusing specifically on ad spend metrics rather than sales or broader insights. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over siblings like shopify_shop_campaign_insights or shopify_sales_by_channel, nor does it specify prerequisites or exclusions. The context is implied (date-range analysis of ad spend) but lacks explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what metrics are shown but doesn't disclose behavioral traits like whether this is a read-only operation, requires specific permissions, has rate limits, returns aggregated vs detailed data, or handles pagination. 'Get' implies reading, but lacks operational context.
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 appropriately sized with two concise sentences that directly address purpose and scope. It's front-loaded with the core function and avoids any unnecessary elaboration, making every sentence earn its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a read operation but has gaps. It covers what metrics are retrieved but lacks details on return format, error handling, or behavioral constraints, which are important for a tool with three parameters and no structured output documentation.
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%, so the schema already documents all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Get customer acquisition and behavior metrics' specifies the verb and resource, and 'Shows new vs returning customers over time' adds scope. It distinguishes from siblings like sales or inventory tools, though not explicitly from all customer-related alternatives.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like shopify_custom_query or shopify_sales_summary that might overlap, there's no indication of when this specific customer metrics tool is preferred or what prerequisites might apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get sales breakdown,' implying a read-only operation, but does not cover aspects like authentication needs, rate limits, error handling, or what the output format looks like (e.g., JSON structure, pagination). For a tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's purpose with no wasted words. It is front-loaded and appropriately sized for its function, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with date parameters) and the absence of annotations and output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, output format, and usage context. With no output schema, the description should ideally hint at return values, but it doesn't, leaving gaps in completeness.
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?
The schema description coverage is 100%, with both parameters ('since' and 'until') well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as explaining how sales channels are defined or if there are default date ranges. Given the high schema coverage, the baseline score of 3 is appropriate.
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?
The description clearly states the verb 'Get' and the resource 'sales breakdown by sales channel', with examples of channels like 'Online Store, POS, etc.' This specifies what the tool does. However, it does not explicitly differentiate from siblings like 'shopify_sales_summary' or 'shopify_sales_by_product', which might offer overlapping or alternative sales data, so it falls short of a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings such as 'shopify_sales_summary' and 'shopify_sales_by_product', it's unclear if this tool is preferred for channel-specific insights or if there are prerequisites like date ranges. No explicit when/when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, the description doesn't mention important behavioral aspects like whether this requires specific permissions, how it handles large datasets, whether results are paginated, or what happens when parameters are omitted. For a data retrieval tool with zero annotation coverage, this is a significant gap.
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 extremely concise with just two sentences that directly state what the tool does and what metrics it returns. Every word earns its place, and the information is front-loaded with no unnecessary verbiage or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a data retrieval tool with 4 parameters and 100% schema coverage but no output schema, the description provides basic purpose but lacks important context. It doesn't explain the return format, what happens with default values, or how to interpret the results. Given the complexity of sales data analysis and the absence of both annotations and output schema, the description should do more to guide usage.
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%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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?
The description clearly states the tool's purpose with specific verbs ('Get sales breakdown') and resources ('by product'), and specifies the metrics returned ('revenue, units sold, and orders per product'). However, it doesn't explicitly differentiate from sibling tools like 'shopify_sales_summary' or 'shopify_sales_over_time', which might offer similar sales data in different formats.
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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools focused on sales data (e.g., 'shopify_sales_by_channel', 'shopify_sales_summary'), there's no indication of when this product-level breakdown is preferred over other sales analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions 'recent orders' and 'checking individual order status', which implies read-only behavior and recency focus, but doesn't disclose critical details like whether this requires authentication, rate limits, pagination behavior, or what 'recent' means (e.g., time window). For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
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?
The description is appropriately sized with two concise sentences that front-load the core purpose ('Get recent orders with details') followed by usage context. There's no wasted verbiage, and each sentence adds value—the first states what it does, the second suggests when to use it. It could be slightly more structured by explicitly mentioning parameters or limitations, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral aspects like authentication, rate limits, or return format. With no output schema, the description doesn't explain what 'details' include or the response structure, leaving gaps for an agent to understand the full context.
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%, so the schema already documents all three parameters (first, status, query) with descriptions and enum values. The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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?
The description clearly states the tool's purpose as 'Get recent orders with details', which specifies the verb ('Get') and resource ('orders with details'). It distinguishes from siblings like shopify_sales_summary or shopify_custom_query by focusing specifically on orders rather than sales analytics or general queries. However, it doesn't explicitly differentiate from all siblings (e.g., shopify_customer_metrics might also involve order data).
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 description provides implied usage guidance with 'Useful for checking individual order status and recent activity', suggesting when this tool is appropriate. However, it doesn't explicitly state when to use this versus alternatives like shopify_custom_query for more complex filtering or shopify_sales_summary for aggregated data. No explicit exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data is retrieved (campaign performance metrics) and the source table, but lacks details on permissions, rate limits, response format, pagination, or error handling. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is concise with two sentences that directly address the tool's function and scope. It avoids unnecessary words and is front-loaded with the core purpose. However, it could be slightly more structured by explicitly separating purpose from scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is minimally adequate. It covers the purpose and scope but lacks details on behavioral aspects like response format, which is critical since there's no output schema. For a data retrieval tool, this leaves gaps in understanding what the tool returns.
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%, so the schema already documents all 5 parameters with descriptions and enums. The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters (e.g., how 'group_by' interacts with 'interval'). Baseline 3 is appropriate when schema does the heavy lifting.
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?
The description clearly states the tool's purpose: 'Get Shop campaign performance metrics (ad spend, sales) from the shop_campaign_insights table.' It specifies the resource (campaign performance metrics) and source (shop_campaign_insights table). However, it doesn't explicitly differentiate from siblings like 'shopify_ad_spend' or 'shopify_sales_by_channel', which might also involve campaign or sales data.
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 description provides some context by mentioning 'Covers Shop channel campaigns (e.g. Shop Pay campaigns)', which implies this tool is for Shop-specific campaigns rather than other types. However, it doesn't explicitly state when to use this tool versus alternatives like 'shopify_ad_spend' or 'shopify_sales_by_channel', nor does it provide exclusions or prerequisites. Usage is implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'useful for trends and comparisons,' which hints at its analytical nature, but fails to disclose critical behaviors like whether it requires authentication, has rate limits, returns paginated results, or what happens with invalid inputs. For a data retrieval tool with zero annotation coverage, this is a significant gap.
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 highly concise and well-structured, consisting of two sentences that efficiently convey the core purpose and utility. Every sentence earns its place: the first states what the tool does, and the second adds context on its usefulness. There is no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, output format, or error handling. Without annotations or an output schema, the agent might struggle with how to interpret results or handle edge cases, making this incomplete for robust usage.
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?
The description does not add any parameter-specific information beyond what the input schema provides. Since schema description coverage is 100%, the schema already documents all parameters (e.g., 'since', 'until', 'interval', 'compare', 'metrics') with descriptions and examples. The baseline score of 3 is appropriate as the schema does the heavy lifting, and the description doesn't compensate with additional semantics.
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?
The description clearly states the tool's purpose: 'Get sales metrics over time as a time series.' It specifies the verb ('Get'), resource ('sales metrics'), and output format ('time series'). However, it doesn't explicitly differentiate from siblings like 'shopify_sales_summary' or 'shopify_sales_by_product', which might offer similar sales data in different formats or scopes.
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 description provides implied usage guidance with 'Useful for trends and comparisons,' suggesting when to use this tool. However, it lacks explicit alternatives or exclusions, such as when to choose this over 'shopify_sales_summary' for aggregated data or 'shopify_sales_by_product' for product-level details. No clear when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the default date range behavior. It doesn't disclose important behavioral traits like whether this requires authentication, rate limits, what happens with invalid dates, or the format/structure of the returned summary. For a read operation with no annotation coverage, this leaves significant gaps.
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 concise sentences that are front-loaded with the core purpose followed by the default behavior. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the summary output looks like, how metrics are calculated, whether data is real-time or cached, or any error conditions. The agent would struggle to use this effectively without trial and error.
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%, so the schema fully documents all three parameters. The description adds minimal value beyond the schema by implying date range filtering but doesn't provide additional context about parameter interactions or semantics. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the verb 'Get' and the resource 'summary of sales metrics' with specific metrics listed (total sales, net sales, orders, AOV, returns, discounts). It distinguishes from siblings like shopify_sales_by_channel or shopify_sales_by_product by focusing on aggregated metrics rather than breakdowns.
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 provides clear context for when to use this tool ('for a date range' with 'Defaults to last 30 days'), which helps differentiate it from tools like shopify_sales_over_time or shopify_custom_query. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool retrieves data (read-only implied by 'Get'), lists returned fields, and mentions filtering support. However, it lacks details on permissions, rate limits, pagination beyond the 'first' parameter, or error handling, leaving behavioral gaps for a tool with no annotation coverage.
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 front-loaded with the core purpose, followed by details on returned data and filtering. It uses two efficient sentences with zero waste, making it easy to scan and understand without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no annotations and no output schema, the description adequately covers the purpose and basic behavior. However, it lacks details on output format (e.g., structure of returned data), error cases, or advanced usage scenarios, which could be important given the tool's complexity and lack of structured output documentation.
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%, so the schema fully documents all three parameters. The description adds minimal value beyond the schema by mentioning filtering by SKU or product title, which aligns with the 'query' parameter's description. No additional syntax or format details are provided, resulting in a baseline score of 3.
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 clearly states the verb ('Get') and resource ('inventory levels for products/variants'), specifying what data is retrieved. It distinguishes from siblings by focusing on inventory rather than sales, customers, or other metrics, making its purpose specific and unambiguous.
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 description implies usage for inventory-related queries but does not explicitly state when to use this tool versus alternatives like sales or order tools. It mentions filtering capabilities but lacks guidance on prerequisites, exclusions, or direct comparisons to sibling tools, leaving usage context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool is for 'advanced analytics' and lists available tables, which adds useful context about scope. However, it doesn't disclose important behavioral traits like authentication requirements, rate limits, query execution time, error handling, or what happens with invalid queries. For a custom query tool with zero annotation coverage, this leaves significant gaps.
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 perfectly concise with two sentences that each earn their place: the first states the purpose and usage guidelines, the second provides essential context about available tables. No wasted words, and information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (custom query execution with no output schema) and zero annotation coverage, the description provides good purpose and usage context but lacks important behavioral details. It doesn't explain what the tool returns, error conditions, or execution constraints. For a powerful analytics tool, more completeness would be helpful despite the concise structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'query' parameter thoroughly. The description adds value by listing available tables (sales, orders, customers, sessions, shop_campaign_insights) which provides semantic context for what can be queried, going beyond the schema's technical requirements. This compensates well despite the high schema coverage.
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 clearly states the tool's purpose with specific verbs ('Run a custom ShopifyQL query') and resources ('advanced analytics'), explicitly distinguishing it from sibling tools by mentioning 'when the pre-built tools don't cover your specific metric needs.' It also lists available tables, providing concrete scope.
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?
The description provides explicit guidance on when to use this tool ('when the pre-built tools don't cover your specific metric needs'), effectively distinguishing it from the many sibling tools listed. It clearly positions this as an alternative for advanced or specific analytics not covered by pre-built options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![shopify-mcp-server MCP server](https://glama.ai/mcp/servers/hamzashahbaz/shopify-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/hamzashahbaz/shopify-mcp-server)

Score Badge

Copy to your README.md:

[![shopify-mcp-server MCP server](https://glama.ai/mcp/servers/hamzashahbaz/shopify-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/hamzashahbaz/shopify-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hamzashahbaz/shopify-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server