Shopify MCP for Claude Code - Everything you need to know

1

如何設定 Shopify 的 MCP 到我的 Claude Code 裡面，以及我的 GitHub，讓我可以開始用 Claude Code 開發？

我已整理好完整的設定流程，包含 Shopify Dev MCP 與 GitHub MCP 兩個部分。以下內容可直接複製貼上使用。

前置準備

在開始前，確認以下環境已就緒：

  • Node.js 18 以上版本已安裝在本機
  • Claude Code CLI 已安裝（npm install -g @anthropic-ai/claude-code），可用 claude --version 確認
  • 已有 Shopify Partner 帳號與開發用商店（development store）
  • GitHub Personal Access Token（PAT），需具備 repo 權限範圍
  • 若走 GitHub 官方 MCP 的本機 Docker 方案，需先安裝並啟動 Docker

設定 Shopify Dev MCP

Shopify 官方提供的 Dev MCP Server 不需要驗證即可在本機執行，適合用來查詢 Shopify 開發文件、GraphQL Admin API schema 等資源 。在終端機（不是在 Claude Code 對話框內）執行以下指令即可加入：

claude mcp add --transport stdio shopify-dev-mcp -- npx -y @shopify/dev-mcp@latest

指令跑完後重新啟動 Claude Code 讓設定生效即可 。如果你想要更完整的功能（不只是查文件，而是能操作你自己商店的產品、訂單、庫存等資料），可以改用社群維護的 Shopify Admin API MCP，例如 ExpertVagabond/shopify-mcp，提供 36 種涵蓋產品、訂單、客戶、庫存、行銷等操作的工具 ，設定方式是在 .mcp.json 中加入對應設定並用環境變數存放 Admin API access token ：

{
  "mcpServers": {
    "shopify-dev-store": {
      "command": "npx",
      "args": ["-y", "@shopify/dev-mcp@latest", "--store", "your-store.myshopify.com", "--token", "${SHOPIFY_ACCESS_TOKEN}"],
      "env": {
        "SHOPIFY_ACCESS_TOKEN": ""
      }
    }
  }
}

Admin API token 需要在 Shopify 後台的 Settings > Apps and sales channels > Develop apps 建立自訂 App 並設定對應的 Admin API scopes（如 read_products、write_products、read_orders 等）才能取得 。

務必把 .mcp.json 加進 .gitignore，絕對不要把含有真實 token 的檔案 commit 上去 ：

echo ".mcp.json" >>.gitignore

設定 GitHub MCP

GitHub 官方也提供了 MCP Server，可讓 Claude Code 直接操作 issue、PR、branch、程式碼搜尋等功能 。目前（Claude Code 2.1.1 以上版本）建議使用遠端 Streamable HTTP 方式設定，不需要 Docker：

claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'

若不想把 token 直接寫在指令裡，建議先存進 .env 檔案再用環境變數帶入 ：

echo "GITHUB_PAT=your_token_here" >>.env
echo -e ".env\n.mcp.json" >>.gitignore
claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer '"$(grep GITHUB_PAT.env | cut -d '=' -f2)"'"}}'

如果偏好本機 Docker 方案（也支援離線 / 內網環境），指令如下 ：

claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=YOUR_GITHUB_PAT -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server

設定完成後記得重新啟動 Claude Code，並用以下指令確認伺服器有正確載入 ：

claude mcp list
claude mcp get github

兩個 MCP 差異比較

項目 Shopify Dev MCP GitHub MCP
用途 查詢 Shopify 開發文件、Admin/GraphQL API schema，或直接操作商店資料（視版本） 操作 GitHub repo：issue、PR、branch、程式碼搜尋等
驗證方式 官方 Dev MCP 免驗證；Admin API 版本需 access token 需要 GitHub PAT，具備 repo 權限範圍
傳輸方式 stdio（透過 npx 執行） 建議用 Streamable HTTP（遠端），或 Docker 本機方案
安裝指令 claude mcp add --transport stdio shopify-dev-mcp -- npx -y @shopify/dev-mcp@latest claude mcp add-json github '{"type":"http",...}'

開始開發的第一步

兩個 MCP 都設定完成後，直接在專案目錄下執行 claude 進入互動模式，Claude Code 會自動分析專案結構並取得 MCP 提供的額外上下文 。你可以馬上試著問它「列出我商店裡所有產品跟庫存」或「幫我在 GitHub 上建立一個新分支並開一個 PR」，來驗證兩個 MCP 都正常運作。

若遇到工具沒出現或連線失敗，可以在 Claude Code 內執行 /mcp 檢查伺服器狀態，或用 claude mcp remove <name> 移除後重新設定一次 。

Shopify Admin API 的最佳實踐與安全設定建議

Shopify Admin API 的安全與效能最佳實踐，核心圍繞在權杖管理、最小權限、Webhook 驗證與速率限制四大主軸，以下整理成可直接套用的實務清單。

驗證方式與權杖管理

Shopify 目前提供三種主要驗證流程：適合嵌入式應用的 Token Exchange（無需跳轉、以 session token 換取 access token）、適合獨立 SaaS 的 Authorization Code Grant（標準 OAuth 2.0 流程），以及適合機器對機器場景的 Client Credentials Grant 。從 2026 年 4 月 1 日起，所有新公開 App 都必須採用會過期的 offline access token（有效期 60 分鐘，refresh token 有效期最長 90 天），取代靜態長效憑證，以降低權杖外洩後的風險範圍 。

實務上建議做法：

  • 權杖必須加密儲存，使用 AES-256-GCM，絕不以明文存放在資料庫或日誌中
  • 用環境變數存放 Client ID、Client Secret 與 access token，絕不寫死在程式碼裡；一旦權杖被 commit 到 Git repo，就應視為已洩漏並立即撤銷
  • 建立主動式 refresh 機制，在權杖到期前 5 到 10 分鐘就換發新權杖，並用 row-level lock 避免並發請求造成的競爭條件
  • 權杖每季輪換一次；若懷疑已洩漏則立即輪換
  • 輪換 Client Secret 時採用重疊期策略：先產生新密鑰、讓 Webhook 同時接受新舊密鑰簽章、用 Dev Dashboard 的臨時 refresh token 遷移現有權杖，最後才撤銷舊密鑰，避免中斷 Webhook 處理

最小權限原則（Scope 管控）

只申請 App 實際需要的 Access Scope，例如僅讀取商品資料就用 read_products，需要處理訂單才加 write_orders，避免申請像 write_inventory 這類非必要的高風險權限 。多店整合時應採用「每店權杖隔離」設計，用專屬的 shops 資料表把每個商店網域對應到各自加密儲存的 access token，並在每次請求時驗證 shop 識別碼與資料庫紀錄相符 。

Webhook 與請求驗證

Webhook 偽造是常見攻擊面，攻擊者可能偽造訂單建立事件讓系統處理假資料。每次收到 Webhook 時都必須用原始請求 body（非解析後的 JSON）搭配 Client Secret 計算 HMAC-SHA256，並用 crypto.timingSafeEqual 做常數時間比較，避免時序攻擊洩漏驗證邏輯 。同時建議用 X-Shopify-Webhook-Id 做去重複處理的 key，因為同一事件 Shopify 可能在 48 小時內重試最多 19 次 。

存取控制與資料最小暴露（OWASP 對應）

Shopify 第三方 App 在 2022 到 2024 年間回報的 47 個安全漏洞中，68% 與 API 驗證或輸入驗證有關 。常見且高風險的漏洞類型與對應防禦：

風險類型 具體情境 防禦措施
Broken Object Level Access (BOLA) 攻擊者遞增訂單 ID 就能撈取所有訂單資料 每次回傳資源前都驗證該資源屬於發起請求的商店；改用 UUID 取代連續數字 ID
屬性層級授權失效 API 回傳了利潤率等內部欄位給前端 用允許清單（allow-list）只回傳必要欄位，而非嘗試黑名單排除
資源濫用 攻擊者以高頻請求打垮後端資料庫 實作速率限制（如每分鐘 30 次），並對資料庫查詢設定 timeout
憑證外洩 Access token 被寫死在程式碼或記錄在錯誤訊息中 用環境變數 + 加密儲存，正式環境關閉 debug 模式

API 速率限制與效能優化

2026 年 Shopify 對 Admin API 的速率限制更嚴格，改採以呼叫複雜度計算成本點數的每日配額模式，簡單讀取消耗較少，寫入與批量操作消耗較多，配額用盡後請求會先進入佇列（最多 1000 筆待處理），超出後直接被拒絕 。建議的優化策略：

  • 優先用 Webhook 訂閱資料變更，取代持續輪詢
  • 對常用資料做回應快取，減少重複請求
  • 用 GraphQL 的批量查詢或 bulkOperationRunQuery 處理大量資料同步，而非逐筆呼叫
  • 遭遇 429 時採用帶隨機抖動（jitter）的指數退避重試策略，並針對每個商店個別追蹤用量，避免單一高流量商店拖累其他商店的請求額度（rate limit cascade）
  • Webhook 處理端應立即回傳 200 OK，再把實際處理邏輯放進佇列非同步執行，避免因處理耗時而觸發 Shopify 重複投遞

正式環境安全清單

上線前建議逐項確認以下項目，這份清單整合了業界對 Shopify App 安全稽核的常見要求 ：

  • 權杖全程加密儲存，日誌中不出現任何 token 或密鑰
  • 所有端點都要求驗證，且都檢查資源歸屬（防範 BOLA）
  • 已啟用速率限制，並針對敏感操作記錄稽核軌跡
  • 所有 Webhook 都通過 HMAC 驗證
  • 正式環境關閉 debug 模式，錯誤訊息不洩漏內部資訊
  • 定期執行 npm audit 等依賴掃描，並視流量規模安排滲透測試（月活躍商戶超過一萬時建議每年做一次專業測試）