shopify-mcp
Shopify MCP 서버
(원하시면 별점을 남겨주세요!)
Shopify API용 MCP 서버로, GraphQL API를 통해 매장 데이터와의 상호작용을 지원합니다. 이 서버는 제품, 고객, 주문 등을 관리하는 도구를 제공합니다.
특징
제품 관리 : 제품 정보 검색 및 검색
고객 관리 : 고객 데이터를 로드하고 고객 태그를 관리합니다.
주문 관리 : 고급 주문 조회 및 필터링
GraphQL 통합 : Shopify의 GraphQL 관리 API와 직접 통합
포괄적인 오류 처리 : API 및 인증 문제에 대한 명확한 오류 메시지
Related MCP server: Shopify MCP Server
필수 조건
Node.js(버전 16 이상)
Shopify 사용자 정의 앱 액세스 토큰(아래 설정 지침 참조)
설정
Shopify 액세스 토큰
이 MCP 서버를 사용하려면 Shopify 스토어에서 사용자 지정 앱을 만들어야 합니다.
Shopify 관리자에서 설정 > 앱 및 판매 채널 로 이동하세요.
앱 개발을 클릭합니다(먼저 개발자 미리보기를 활성화해야 할 수도 있음)
앱 만들기를 클릭하세요
앱 이름을 설정합니다(예: "Shopify MCP 서버")
관리 API 범위 구성을 클릭하세요.
다음 범위를 선택하세요:
read_products,write_productsread_customers,write_customersread_orders,write_orders
저장을 클릭하세요
앱 설치를 클릭하세요
설치를 클릭하여 앱에 스토어 데이터에 대한 액세스 권한을 부여하세요.
설치 후 Admin API 액세스 토큰이 표시됩니다.
이 토큰을 복사하세요. 구성에 필요합니다.
Claude Desktop과 함께 사용
claude_desktop_config.json 에 다음을 추가하세요:
지엑스피1
Claude Desktop 구성 파일의 위치:
MacOS:
~/Library/Application Support/Claude/claude_desktop_config.json윈도우:
%APPDATA%/Claude/claude_desktop_config.json
대안: 환경 변수를 사용하여 로컬로 실행
명령줄 인수 대신 환경 변수를 사용하려면 다음을 수행합니다.
Shopify 자격 증명으로
.env파일을 만듭니다.SHOPIFY_ACCESS_TOKEN=your_access_token MYSHOPIFY_DOMAIN=your-store.myshopify.comnpx로 서버를 실행합니다:
npx shopify-mcp-server
직접 설치(선택 사항)
패키지를 글로벌하게 설치하려면:
npm install -g shopify-mcp-server그런 다음 실행합니다.
shopify-mcp-server --accessToken=<YOUR_ACCESS_TOKEN> --domain=<YOUR_SHOP>.myshopify.com사용 가능한 도구
제품 관리
get-products모든 제품을 가져오거나 제목으로 검색하세요
입력:
searchTitle(선택 문자열): 제목으로 제품 필터링limit(숫자): 반품할 최대 제품 수
get-product-by-idID로 특정 제품 가져오기
입력:
productId(문자열): 검색할 제품의 ID
고객 관리
get-customers고객을 확보하거나 이름/이메일로 검색하세요
입력:
searchQuery(선택 문자열): 이름 또는 이메일로 고객 필터링limit(선택적 숫자, 기본값: 10): 반환할 최대 고객 수
update-customer고객 정보 업데이트
입력:
id(문자열, 필수): Shopify 고객 ID(숫자 ID만 가능, 예: "6276879810626")firstName(문자열, 선택 사항): 고객의 이름lastName(문자열, 선택 사항): 고객의 성email(문자열, 선택 사항): 고객의 이메일 주소phone(문자열, 선택 사항): 고객의 전화번호tags(문자열 배열, 선택 사항): 고객에게 적용할 태그note(문자열, 선택 사항): 고객에 대한 참고 사항taxExempt(부울, 선택 사항): 고객이 세금 면제 대상인지 여부metafields(객체 배열, 선택 사항): 추가 데이터를 저장하기 위한 고객 메타필드
get-customer-orders특정 고객에 대한 주문을 받으세요
입력:
customerId(문자열, 필수): Shopify 고객 ID(숫자 ID만 가능, 예: "6276879810626")limit(선택적 숫자, 기본값: 10): 반환할 최대 주문 수
주문 관리
get-orders선택적 필터링으로 주문 받기
입력:
status(선택 문자열): 주문 상태별 필터링limit(선택적 숫자, 기본값: 10): 반환할 최대 주문 수
get-order-by-idID로 특정 주문 받기
입력:
orderId(문자열, 필수): 전체 Shopify 주문 ID(예: "gid://shopify/Order/6090960994370")
update-order기존 주문을 새로운 정보로 업데이트
입력:
id(문자열, 필수): Shopify 주문 IDtags(문자열 배열, 선택 사항): 주문에 대한 새 태그email(문자열, 선택 사항): 고객 이메일 업데이트note(문자열, 선택 사항): 주문 메모customAttributes(객체 배열, 선택 사항): 주문에 대한 사용자 정의 속성metafields(객체 배열, 선택 사항): 메타필드 정렬shippingAddress(객체, 선택 사항): 배송 주소 정보
디버깅
문제가 발생하면 Claude Desktop의 MCP 로그를 확인하세요.
tail -n 20 -f ~/Library/Logs/Claude/mcp*.log특허
MIT
Available Tools
5 toolsget-customersD
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| searchQuery | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-ordersD
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | any |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-product-by-idD
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get-productsD
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| searchTitle | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update-orderD
| Name | Required | Description | Default |
|---|---|---|---|
| customAttributes | No | ||
| No | |||
| id | Yes | ||
| metafields | No | ||
| note | No | ||
| shippingAddress | No | ||
| tags | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v1.0.0- First observed
get-customers - First observed
get-orders - First observed
get-product-by-id - First observed
get-products - First observed
update-order
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose targeting specific Shopify resources: customers, orders, products, and order updates. There is no overlap in functionality, making it easy for an agent to select the correct tool for each task without confusion.
The naming follows a consistent verb-noun pattern with hyphens (e.g., get-customers, update-order), which is predictable and readable. The minor deviation is that 'get-product-by-id' includes a preposition, slightly breaking the pure verb-noun style, but overall the pattern is clear and mostly uniform.
With 5 tools, the count is reasonable for a Shopify integration, but it feels borderline thin for covering the domain comprehensively. While core read operations are present, the scope might benefit from additional tools for full CRUD or lifecycle coverage, such as creating or deleting resources.
The tool set has significant gaps for a Shopify server, focusing heavily on read operations (get-customers, get-orders, get-products) with only one update tool (update-order). Missing are create and delete operations for customers, orders, and products, as well as other common actions like inventory management or webhook handling, which limits agent workflows and could lead to failures in broader tasks.
Maintenance
Related MCP Connectors
Shopify MCP Pack — wraps the Shopify Admin REST API (2024-01)
Manage a Shopify store's Sternify bundles, gifts, upsells, banners and reviews via OAuth.
The public product catalogue and collections of any Shopify storefront, as structured JSON.
Read store products, orders, customers, categories and coupons; adjust inventory and update orders.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables interaction with Shopify store data using the GraphQL API, supporting product, customer, and order management with comprehensive error handling.15125 npm18MIT
- -licenseNot gradedqualityNot gradedmaintenanceEnables interaction with Shopify store data via GraphQL API, providing tools for managing products, customers, orders, discounts, and more with robust error handling.125 npm30-
- AlicenseNot gradedqualityDmaintenanceEnables interaction with Shopify stores through GraphQL API, providing tools for managing products, customers, orders, and more.125 npm10MIT
- AlicenseCqualityDmaintenanceEnables interaction with Shopify store data through GraphQL API, providing tools for managing products, customers, orders, blogs, and articles.152,216 npm4MIT