Provides tools for interacting with the Shopify Admin API, enabling management of products, orders, customers, collections, inventory, and shop information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-shopify list all products in my store"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Shopify Admin API.
Add this to your Claude Desktop configuration:
{
"mcpServers": {
"mcp-shopify": {
"command": "npx",
"args": ["-y", "@cloud9-labs/mcp-shopify"],
"env": {
"SHOPIFY_STORE_URL": "YOUR_STORE_URL",
"SHOPIFY_ACCESS_TOKEN": "YOUR_ACCESS_TOKEN"
}
}
}
}Related MCP server: shopify-mcp
Set the following environment variables:
Variable | Description |
| Your Shopify store URL (e.g., mystore.myshopify.com) |
| Admin API access token |
Tool | Description |
| List all products in Shopify store |
| Get a specific product by ID |
| Create a new product |
| Update an existing product |
| List all orders |
| Get a specific order by ID |
| List all customers |
| Get a specific customer by ID |
| Create a new customer |
| Search for customers |
| List all product collections |
| Get inventory levels for products |
| Get total product count |
| Get shop information |
MIT
Count products with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | No | ||
| product_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Count products' communicates a non-mutating aggregate operation, but it does not explain return shape, filtering behavior, or whether both filters combine. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single direct sentence with no wasted words. It front-loads the operation, though it is perhaps too terse to fully support an agent making a correct call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two optional filters and no output schema, so the description is close to minimally viable. However, it lacks key context such as how filters apply, what the response contains, and how this differs from list_products, leaving meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only says 'optional filters,' which adds little beyond the raw property names vendor and product_type. No detail is given about matching semantics, allowed values, or how the filters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: count products. It also mentions optional filters, which distinguishes it from list_products in intent, though it does not explicitly name any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool instead of shopify_list_products or other siblings. It implies use for counting, but there is no explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new customer.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| Yes | |||
| phone | No | ||
| last_name | No | ||
| first_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It says only that it creates a customer, with no mention of side effects, auth requirements, duplicate email handling, or response behavior. Even the basic mutation implication is already present in the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification, not conciseness. A single tautological sentence contains no structured information and does not earn its place beyond repeating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, one required, no parameter descriptions, and no output schema, this description is entirely inadequate. An agent cannot determine acceptable formats, required fields beyond email, tagging conventions, or what a successful creation returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any of the five parameters. Fields like tags, phone, and first_name are left completely undocumented, and the description adds no meaning to email's required role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new customer.' literally restates the tool name shopify_create_customer, adding no new information about the operation. It is a clear verb+resource but is a tautology rather than a purpose statement that distinguishes it from siblings like shopify_create_product or shopify_search_customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as shopify_create_product, shopify_update_product, or shopify_search_customers. The description omits any context about prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new product.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | Yes | ||
| images | No | ||
| status | No | ||
| vendor | No | ||
| variants | No | ||
| body_html | No | ||
| product_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Create a new product' reveals only the basic action, with no mention of side effects, defaults, required permissions, or whether the product is immediately published.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. However, it is under-specified rather than efficiently informative; a good concise description would still mention key aspects like the required title field or default status.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations, no output schema, and a rich 8-parameter input schema, this one-liner is severely incomplete. It provides no context about return behavior, defaults, or edge cases, leaving the agent unable to predict the outcome of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description names none of the 8 parameters. It leaves the agent to infer meaning solely from raw parameter names like 'tags', 'variants', and 'body_html', without any guidance on required fields, formats, or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a direct verb ('Create') and a specific resource ('product'), making the core intent clear. However, it does not differentiate from sibling tools like shopify_update_product, relying on the name alone for disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of typical scenarios, prerequisites, or exclusions relative to shopify_list_products or shopify_update_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a customer by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| customerId | Yes |
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. 'Get' implies a read operation, but the description does not mention error behavior, authentication requirements, rate limits, or whether the returned object includes addresses, tags, or other fields. For a tool with no annotations, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It fully answers the basic 'what does this tool do' question in minimal words, which is ideal for an agent parsing a tool list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a single-parameter get-by-ID operation, the description is minimally adequate for making the call. However, with no output schema and no annotations, returning behavior and expected payload shape are left unspecified, so the description is not as complete as it could be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the sole parameter, but it only restates that the customer is fetched by ID. The schema already documents customerId as a positive integer; the description does not add meaningful semantics such as where the ID comes from, whether it supports external IDs, or how invalid IDs are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource, 'Get a customer by ID,' which clearly conveys a single-customer retrieval operation. The 'by ID' qualifier distinguishes it from list/search customer tools, though it does not explicitly reference them or describe what fields are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when a customer's ID is known, but it gives no explicit guidance on when to choose this over alternatives like shopify_search_customers or shopify_list_customers. There is no mention of prerequisites or exclusions, leaving the usage context mostly inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get inventory levels by item or location IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| location_ids | No | ||
| inventory_item_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It communicates a read operation through 'get' but does not mention pagination behavior, whether at least one ID filter is required, how limits apply, or whether calling with no IDs returns all inventory levels. These are material gaps for an agent deciding how to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise front-loaded sentence with no filler. It conveys the core action and the main filtering dimensions efficiently, though it could have used the brevity to add a key parameter detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and zero schema description coverage, the one-line description leaves the agent without essential context such as the meaning of the limit parameter, the format of ID strings, and whether either ID filter is required. It is minimally sufficient to guess the tool's purpose but not complete enough for confident correct invocation in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter documentation gap. It does clarify that inventory_item_ids and location_ids are filters, but it does not explain the expected string format (e.g., comma-separated IDs) and completely omits the limit parameter. Thus the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a specific verb ('Get'), a clear resource ('inventory levels'), and the key filtering dimensions ('by item or location IDs'). It is immediately distinguishable from all sibling tools, none of which target inventory levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving inventory levels when item or location IDs are relevant, and no sibling offers the same capability. However, it does not explicitly state when to use this tool over alternatives or when not to use it, leaving some inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an order by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must carry the burden of behavioral disclosure. 'Get' weakly implies a read-only operation, but the description does not mention error behavior, response contents, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One focused sentence with no filler, and the core action plus identifier mode are front-loaded. This is appropriately concise for a one-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the absence of annotations and output schema leaves the agent without information about return shape or failure modes. There is also no mention of the more general order-listing tool for comparison, so the description is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers only 'by ID,' adding little beyond the schema's property name orderId. With 0% schema description coverage, the description should explain what kind of identifier this is or how it should be formatted, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('an order'), with 'by ID' clarifying that this is a single-record fetch rather than a list operation. This distinguishes it from sibling shopify_list_orders while following the same naming convention as other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the sibling list_orders or whether additional prerequisites exist. An agent must infer that this is appropriate when an order ID is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a product by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. The word 'Get' communicates a read-only retrieval, and there are no obvious destructive side effects, but the description does not mention error behavior, authorization needs, or what is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. The key information is front-loaded and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool, this is minimally adequate, but it leaves gaps: it does not clarify the identifier semantics, what product data is returned, or how to handle not-found cases. It is not as rich as it could be for a Shopify-specific API call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no real meaning beyond the schema's existing 'productId' property name. It does not clarify that this is the Shopify numeric product ID, not an SKU, handle, or external identifier, so the lone required parameter is not fully explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('product') and identifies the uniqueness criterion ('by ID'). This clearly separates it from siblings like shopify_list_products, shopify_create_product, and shopify_update_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies this tool should be used when the agent has a specific product ID, but it does not explicitly say when not to use it or name alternatives. No guidance is given about using shopify_list_products for browsing products or how to obtain a product ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get shop information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Get shop information' only implies a read operation and gives no information about authentication requirements, side effects, rate limits, or response behavior. It adds little beyond what the tool name already communicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It fully accomplishes its limited job for a zero-parameter tool without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool, 'Get shop information' is minimally adequate, but the absence of an output schema and annotations leaves gaps. There is no description of what data fields are returned or any behavioral caveats, so the definition is serviceable but not fully complete for an agent that may need to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain about parameter semantics. The baseline for zero-parameter tools is 4, and the description does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get shop information.' This clearly identifies the target of the tool and distinguishes it from sibling tools that operate on products, orders, customers, or collections. It is not a tautology because it adds 'shop information' as the object of the get operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this tool when you need information about the shop itself rather than products, orders, or customers. However, it provides no explicit guidance on when to prefer this tool over alternatives or any conditions/exclusions, leaving the usage context implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List collections with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. 'List' implies a read operation and 'with pagination' signals limited results, but it does not explain how pagination works, whether cursors/pages are used, or what the response contains. This is acceptable for a simple list tool 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundant information. It front-loads the core action and resource, and every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter, the description is adequate at a high level. However, since there is no output schema, the absence of return-value details or pagination mechanics leaves some ambiguity for an agent deciding whether the response is sufficient for downstream use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the schema itself is self-explanatory for the single 'limit' parameter, with type, default, and maximum. The description's 'pagination' hints at the limit's purpose, but it does not explicitly describe how the limit controls page size or how consumers should paginate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a resource ('collections'), and a behavioral detail ('pagination'), so an agent can tell what the tool operates on. It is clear and distinct from sibling tools, though it does not explicitly scope the listing to 'all collections' or define the collection type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource name: use this when you need to list collections, not products, orders, or customers. However, the description provides no explicit when-to-use guidance, exclusions, or mention of an alternative collection-specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List customers with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| page_info | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states 'List customers with pagination.' It does not disclose that this is a read-only operation, how pagination works, whether it returns full customer objects, or any limits/rate considerations. This is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler: verb, resource, and key behavior are all present. Every word earns its place, and there is no redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is too sparse for fully confident invocation. It mentions pagination but omits how to handle page_info, what default limit applies, whether more pages exist, and what the response structure looks like. Contextual completeness is only slightly better than a bare name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two params. It vaguely relates to 'pagination' but does not explain that limit controls page size (default 50, max 250) or that page_info is a cursor token. The parameter names are somewhat self-explanatory, but the description adds little semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), resource ('customers'), and a key behavior ('with pagination'), which distinguishes it from get_customer and search_customers at a surface level. It does not explicitly state scope or contrast itself with sibling tools, so it misses full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like shopify_search_customers or shopify_get_customer. There are no exclusions, prerequisites, or context cues, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List orders with filtering options.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| financial_status | No | ||
| fulfillment_status | No |
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, yet it only says 'List orders.' It implies a read-only operation but says nothing about pagination behavior (limit defaults to 50, max 250), result ordering, or response shape. There is no annotation contradiction since no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single five-word sentence that front-loads the action verb and resource with zero wasted words. It is efficient and well-structured, though arguably too terse for a tool with 4 parameters and no annotation support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% parameter coverage, this minimal description leaves too much unstated: default limit behavior, pagination implications, and the relationship to shopify_get_order. The schema defines the parameter space, but the description adds little beyond the core operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only refers generically to 'filtering options' without explaining any parameter. The enum names (status, financial_status, fulfillment_status) are moderately self-explanatory, yet the description itself adds no semantic detail beyond what the property names convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('orders'), and the phrase 'with filtering options' hints at the parameterized nature of the tool. It is clearly distinct from shopify_get_order by the plural/singular convention, though it does not explicitly call out that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus shopify_get_order or the other list tools. 'With filtering options' implies filtered retrieval of orders, but no usage conditions, exclusions, or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products with pagination and filtering options.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| page_info | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that the tool lists products with pagination and filtering, but does not disclose what data is returned, whether only active products are shown by default, how page_info is expected to be used, or any side effects or permissions. Since this is a read operation, the lack of damage disclosure is less critical, but the behavior is still under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant wording. It front-loads the action and resource and gives a brief hint of capabilities. It is appropriately concise for a simple list operation, though it sacrifices completeness for brevity, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not explain pagination semantics (e.g., how to request the next page), the meaning or default behavior of status, or what the response looks like. An agent would have to guess or rely on external knowledge to use this tool correctly beyond a basic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It only mentions 'pagination and filtering options' without mapping them to limit, page_info, and status. An agent cannot tell from the description which parameters control pagination versus filtering, nor what the status enum values mean in context. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('products'), and mentions pagination and filtering, which clearly signals this is a collection-retrieval tool. It differentiates from siblings like shopify_get_product, shopify_create_product, and shopify_update_product by focusing on listing, and from shopify_count_products by implying a detailed result set with pagination. However, it does not explicitly contrast with count_products, so it is 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.
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 instead of alternatives. It does not mention that shopify_get_product should be used for a single product, shopify_count_products for totals, or how pagination/filtering should be leveraged. The phrase 'with pagination and filtering options' suggests some use cases but leaves the decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search customers by query string.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning read-only behavior, pagination, match semantics, rate limits, or failure modes, leaving the agent to guess important runtime properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler, and the action and object are immediately clear. It is appropriately brief for a one-parameter search tool, though the brevity comes at the cost of informative detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable: it identifies the action and required input, and the tool is simple with one parameter and no output schema. However, it omits search-field semantics and any behavioral notes, leaving clear gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description's 'query string' adds no meaning beyond the schema's 'query' property name. It doesn't explain what the query matches against (e.g., name, email, phone) or any formatting expectations beyond minLength.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('search customers') and clearly implies query-based lookup, distinguishing it from list_customers and get_customer. However, it doesn't specify which customer fields are searched, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of siblings like list_customers or get_customer. The description conveys no selection criteria, exclusions, or context that would help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing product.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | No | ||
| status | No | ||
| vendor | No | ||
| body_html | No | ||
| productId | Yes | ||
| product_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the mutation ('Update') without explaining partial-update behavior, whether unspecified fields are preserved, required product existence, or response/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, making it concise and front-loaded. However, it is minimal to the point of under-specification, so it cannot earn higher marks for being appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, no output schema, and no usage details, the description is not complete enough for reliable tool selection and invocation. Important context such as update semantics, return value, and error cases is entirely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names no parameters or adds any meaning beyond the schema's field names. An agent receives no guidance on how tags, title, status, vendor, body_html, or product_type relate to the update operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Update') and resource ('existing product'), distinguishing it from sibling read/create/list tools. However, it does not specify which fields are updatable or mention any scope details, so it is clear but not richly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording 'existing product' implies this tool is for modifying an already-created product, but there is no explicit when-to-use guidance, prerequisites, or exclusions. An agent can infer the use case, but the description does not actively steer toward or away from any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0shopify_count_productsshopify_create_customershopify_create_productshopify_get_customershopify_get_inventory_levelsshopify_get_ordershopify_get_productshopify_get_shopshopify_list_collectionsshopify_list_customersshopify_list_ordersshopify_list_productsshopify_search_customersshopify_update_productTool names clearly separate resources and actions, making most purposes obvious. The only possible confusion is between list_customers and search_customers, though their descriptions indicate different input modes.
All tools follow a consistent shopify_verb_noun pattern using snake_case. Action verbs like list, get, create, update, count, and search are applied uniformly across resources.
14 tools is a well-scoped size for a Shopify MCP server, covering the core resources without bloating the surface. Each tool serves a distinct purpose and the set remains navigable.
Products have solid CRUD coverage, but orders are read-only and customers lack update/delete operations. Collections and inventory are also minimally covered, with list-only and get-only tools respectively, leaving notable lifecycle gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
Shopify MCP Pack — wraps the Shopify Admin REST API (2024-01)
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
AI commerce for Shopify: product search, comparison, recommendations, and checkout via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cloud9-labs/mcp-shopify'
If you have feedback or need assistance with the MCP directory API, please join our Discord server