Skip to main content
Glama

Shopify MCP 서버

(원하시면 별점을 남겨주세요!)

Shopify API용 MCP 서버로, GraphQL API를 통해 매장 데이터와의 상호작용을 지원합니다. 이 서버는 제품, 고객, 주문 등을 관리하는 도구를 제공합니다.

특징

  • 제품 관리 : 제품 정보 검색 및 검색

  • 고객 관리 : 고객 데이터를 로드하고 고객 태그를 관리합니다.

  • 주문 관리 : 고급 주문 조회 및 필터링

  • GraphQL 통합 : Shopify의 GraphQL 관리 API와 직접 통합

  • 포괄적인 오류 처리 : API 및 인증 문제에 대한 명확한 오류 메시지

Related MCP server: Shopify MCP Server

필수 조건

  1. Node.js(버전 16 이상)

  2. Shopify 사용자 정의 앱 액세스 토큰(아래 설정 지침 참조)

설정

Shopify 액세스 토큰

이 MCP 서버를 사용하려면 Shopify 스토어에서 사용자 지정 앱을 만들어야 합니다.

  1. Shopify 관리자에서 설정 > 앱 및 판매 채널 로 이동하세요.

  2. 앱 개발을 클릭합니다(먼저 개발자 미리보기를 활성화해야 할 수도 있음)

  3. 앱 만들기를 클릭하세요

  4. 앱 이름을 설정합니다(예: "Shopify MCP 서버")

  5. 관리 API 범위 구성을 클릭하세요.

  6. 다음 범위를 선택하세요:

    • read_products , write_products

    • read_customers , write_customers

    • read_orders , write_orders

  7. 저장을 클릭하세요

  8. 앱 설치를 클릭하세요

  9. 설치를 클릭하여 앱에 스토어 데이터에 대한 액세스 권한을 부여하세요.

  10. 설치 후 Admin API 액세스 토큰이 표시됩니다.

  11. 이 토큰을 복사하세요. 구성에 필요합니다.

Claude Desktop과 함께 사용

claude_desktop_config.json 에 다음을 추가하세요:

지엑스피1

Claude Desktop 구성 파일의 위치:

  • MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • 윈도우: %APPDATA%/Claude/claude_desktop_config.json

대안: 환경 변수를 사용하여 로컬로 실행

명령줄 인수 대신 환경 변수를 사용하려면 다음을 수행합니다.

  1. Shopify 자격 증명으로 .env 파일을 만듭니다.

    SHOPIFY_ACCESS_TOKEN=your_access_token
    MYSHOPIFY_DOMAIN=your-store.myshopify.com
  2. npx로 서버를 실행합니다:

    npx shopify-mcp-server

직접 설치(선택 사항)

패키지를 글로벌하게 설치하려면:

npm install -g shopify-mcp-server

그런 다음 실행합니다.

shopify-mcp-server --accessToken=<YOUR_ACCESS_TOKEN> --domain=<YOUR_SHOP>.myshopify.com

사용 가능한 도구

제품 관리

  1. get-products

    • 모든 제품을 가져오거나 제목으로 검색하세요

    • 입력:

      • searchTitle (선택 문자열): 제목으로 제품 필터링

      • limit (숫자): 반품할 최대 제품 수

  2. get-product-by-id

    • ID로 특정 제품 가져오기

    • 입력:

      • productId (문자열): 검색할 제품의 ID

고객 관리

  1. get-customers

    • 고객을 확보하거나 이름/이메일로 검색하세요

    • 입력:

      • searchQuery (선택 문자열): 이름 또는 이메일로 고객 필터링

      • limit (선택적 숫자, 기본값: 10): 반환할 최대 고객 수

  2. update-customer

    • 고객 정보 업데이트

    • 입력:

      • id (문자열, 필수): Shopify 고객 ID(숫자 ID만 가능, 예: "6276879810626")

      • firstName (문자열, 선택 사항): 고객의 이름

      • lastName (문자열, 선택 사항): 고객의 성

      • email (문자열, 선택 사항): 고객의 이메일 주소

      • phone (문자열, 선택 사항): 고객의 전화번호

      • tags (문자열 배열, 선택 사항): 고객에게 적용할 태그

      • note (문자열, 선택 사항): 고객에 대한 참고 사항

      • taxExempt (부울, 선택 사항): 고객이 세금 면제 대상인지 여부

      • metafields (객체 배열, 선택 사항): 추가 데이터를 저장하기 위한 고객 메타필드

  3. get-customer-orders

    • 특정 고객에 대한 주문을 받으세요

    • 입력:

      • customerId (문자열, 필수): Shopify 고객 ID(숫자 ID만 가능, 예: "6276879810626")

      • limit (선택적 숫자, 기본값: 10): 반환할 최대 주문 수

주문 관리

  1. get-orders

    • 선택적 필터링으로 주문 받기

    • 입력:

      • status (선택 문자열): 주문 상태별 필터링

      • limit (선택적 숫자, 기본값: 10): 반환할 최대 주문 수

  2. get-order-by-id

    • ID로 특정 주문 받기

    • 입력:

      • orderId (문자열, 필수): 전체 Shopify 주문 ID(예: "gid://shopify/Order/6090960994370")

  3. update-order

    • 기존 주문을 새로운 정보로 업데이트

    • 입력:

      • id (문자열, 필수): Shopify 주문 ID

      • tags (문자열 배열, 선택 사항): 주문에 대한 새 태그

      • email (문자열, 선택 사항): 고객 이메일 업데이트

      • note (문자열, 선택 사항): 주문 메모

      • customAttributes (객체 배열, 선택 사항): 주문에 대한 사용자 정의 속성

      • metafields (객체 배열, 선택 사항): 메타필드 정렬

      • shippingAddress (객체, 선택 사항): 배송 주소 정보

디버깅

문제가 발생하면 Claude Desktop의 MCP 로그를 확인하세요.

tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

특허

MIT

Available Tools

5 tools
get-customersD
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
searchQueryNo

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
statusNoany

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
productIdYes

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
searchTitleNo

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
customAttributesNo
emailNo
idYes
metafieldsNo
noteNo
shippingAddressNo
tagsNo

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

  1. 5 tool updatesv1.0.0
    • First observedget-customers
    • First observedget-orders
    • First observedget-product-by-id
    • First observedget-products
    • First observedupdate-order

TDQS

D1.8/5.0

Scored across 5 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers