Which integrations are available for this server?

Provides comprehensive tools for managing BigCommerce stores, including retrieving and filtering products, managing customers with advanced search options, and accessing order data with customer-product relationship capabilities through the BigCommerce REST API.

How do I use BigCommerce API MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@BigCommerce API MCP Server show me all orders from the last week" 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.

BigCommerce API MCP Server

by etugrand

Overview Schema Related Servers Score Discussions

JavaScript

Remote

BigCommerce MCP Server

A comprehensive Model Context Protocol (MCP) server for BigCommerce REST API integration. This server provides AI assistants with the ability to interact with BigCommerce stores through three powerful tools:

🛍️ Products Management: Get all products with advanced filtering
👥 Customer Management: Retrieve and filter customers with comprehensive search options
📦 Order Management: Access orders with customer-product relationship capabilities

✨ Features

✅ MCP-compatible server with built-in tool discovery
✅ Enhanced filtering capabilities on all endpoints
✅ Customer-product association through order history
✅ Comprehensive error handling and validation
✅ Docker support for production deployment
✅ Compatible with Claude Desktop, Cline, and other MCP clients

Related MCP server: commercetools Commerce MCP

🚦 Getting Started

⚙️ Prerequisites

Node.js (v18+ required, v20+ recommended)
npm (included with Node)
BigCommerce store with API credentials

📥 Installation & Setup

1. Clone and install dependencies

git clone https://github.com/isaacgounton/bigcommerce-api-mcp.git
cd bigcommerce-api-mcp
npm install

2. Configure your BigCommerce credentials

Create a .env file in the project root:

BIGCOMMERCE_STORE_HASH=your_store_hash_here
BIGCOMMERCE_API_KEY=your_api_key_here

How to get your BigCommerce credentials:

Go to your BigCommerce admin panel
Navigate to Advanced Settings > API Accounts
Create a new API account with the following scopes:
- Products: Read-only or Modify
- Orders: Read-only or Modify
- Customers: Read-only or Modify
Copy the Store Hash and Access Token to your .env file

🔧 Available Tools

get_all_products

Retrieve products from your BigCommerce store
Parameters: store_Hash (required)

get_all_customers

Search and filter customers with advanced options
Parameters: store_Hash (required)
Optional filters: email, name, company, phone, customer_group_id, limit, page, date_created, date_modified

get_all_orders

Access orders with customer-product relationship data
Parameters: store_Hash (required)
Optional filters: customer_id, email, status_id, min_id, max_id, limit, page
✨ Special feature: Filter by customer_id to see all products associated with a specific customer

🔗 Client Integration

💬 Claude Desktop

Step 1: Get the absolute paths to node and mcpServer.js:

which node
# Example output: /usr/bin/node

realpath mcpServer.js  
# Example output: /home/user/bigcommerce-api-mcp/mcpServer.js

Step 2: Open Claude Desktop → Settings → Developer → Edit Config and add:

{
  "mcpServers": {
    "bigcommerce": {
      "command": "/usr/bin/node",
      "args": ["/absolute/path/to/your/mcpServer.js"],
      "env": {
        "BIGCOMMERCE_STORE_HASH": "your_store_hash_here",
        "BIGCOMMERCE_API_KEY": "your_api_key_here"
      }
    }
  }
}

Step 3: Restart Claude Desktop. Look for a green circle next to "bigcommerce" in the MCP section.

� Cline (VS Code Extension)

Step 1: Install the Cline extension in VS Code

Step 2: Open VS Code settings and search for "Cline MCP"

Step 3: Add your MCP server configuration:

{
  "cline.mcp.servers": {
    "bigcommerce": {
      "command": "node",
      "args": ["/absolute/path/to/mcpServer.js"],
      "env": {
        "BIGCOMMERCE_STORE_HASH": "your_store_hash_here", 
        "BIGCOMMERCE_API_KEY": "your_api_key_here"
      }
    }
  }
}

🤖 Other MCP Clients

For any MCP-compatible client, use these connection details:

Command: node
Args: ["/path/to/mcpServer.js"]
Environment Variables:
- BIGCOMMERCE_STORE_HASH
- BIGCOMMERCE_API_KEY

🐳 Docker Deployment

Quick Start

1. Build the Docker image:

docker build -t bigcommerce-mcp .

2. Run with environment variables:

docker run -i --rm \
  -e BIGCOMMERCE_STORE_HASH=your_store_hash \
  -e BIGCOMMERCE_API_KEY=your_api_key \
  bigcommerce-mcp

Claude Desktop with Docker

Update your Claude Desktop config to use Docker:

{
  "mcpServers": {
    "bigcommerce": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", 
        "-e", "BIGCOMMERCE_STORE_HASH=your_store_hash",
        "-e", "BIGCOMMERCE_API_KEY=your_api_key", 
        "bigcommerce-mcp"
      ]
    }
  }
}

Docker Compose (Production)

Create a docker-compose.yml:

version: '3.8'
services:
  bigcommerce-mcp:
    build: .
    environment:
      - BIGCOMMERCE_STORE_HASH=${BIGCOMMERCE_STORE_HASH}
      - BIGCOMMERCE_API_KEY=${BIGCOMMERCE_API_KEY}
    restart: unless-stopped

Then run:

docker-compose up -d

🧪 Testing

Local Testing

Test the server locally to ensure it's working:

# Test tool discovery
echo '{"jsonrpc":"2.0","method":"tools/list","params":{},"id":1}' | node mcpServer.js

# Test a tool call  
echo '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"get_all_products","arguments":{"store_Hash":"your_store_hash"}},"id":2}' | node mcpServer.js

Postman Integration (Optional)

You can also test with Postman Desktop:

Download Postman Desktop
Create a new MCP request with type STDIO
Set command to: node /absolute/path/to/mcpServer.js
Test your tools before connecting to AI clients

🛠️ Advanced Usage

Server Modes

Standard stdio mode (default):

node mcpServer.js

HTTP mode with Server-Sent Events:

node mcpServer.js --sse

Streamable HTTP mode:

node mcpServer.js --streamable-http

Environment Variables

All BigCommerce credentials can be provided via environment variables:

export BIGCOMMERCE_STORE_HASH="your_store_hash"
export BIGCOMMERCE_API_KEY="your_api_key" 
node mcpServer.js

🔍 Tool Examples

Find products associated with a customer

// Use get_all_orders with customer_id filter
{
  "name": "get_all_orders", 
  "arguments": {
    "store_Hash": "your_store_hash",
    "customer_id": "3"
  }
}

Search customers by email

// Use get_all_customers with email filter
{
  "name": "get_all_customers",
  "arguments": {
    "store_Hash": "your_store_hash", 
    "email": "customer@example.com"
  }
}

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

📄 License

This project is licensed under the MIT License.

🆘 Support & Questions

🐛 Issues: GitHub Issues
💬 Discussions: GitHub Discussions
📖 MCP Documentation: Model Context Protocol
🏪 BigCommerce API Docs: BigCommerce API Reference

🚀 What's Next?

This MCP server provides a solid foundation for BigCommerce integration. Possible enhancements include:

Additional BigCommerce API endpoints (categories, brands, etc.)
Webhook support for real-time updates
Advanced filtering and search capabilities
Multi-store support
Product modification tools (create/update/delete)

Built with ❤️ for the MCP community

Available Tools

3 tools

get_all_customersC

Get all customers from the BigCommerce API with comprehensive filtering options (email, name, company, phone, customer group, dates, pagination). Store hash is automatically retrieved from environment variables.

ParametersJSON Schema

Name	Required	Description
`company`	No	Filter by company name (exact match).
`customer_group_id`	No	Filter by customer group ID (comma-separated for multiple groups).
`date_created`	No	Filter by exact customer creation date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS).
`date_created_max`	No	Filter customers created before this date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS).
`date_created_min`	No	Filter customers created after this date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS).
`date_modified`	No	Filter by exact customer modification date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS).
`date_modified_max`	No	Filter customers modified before this date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS).
`date_modified_min`	No	Filter customers modified after this date (ISO format: YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS).
`email`	No	Filter by customer email address (exact match).
`id`	No	Filter by customer IDs (comma-separated for multiple IDs, e.g., "1,2,3").
`include`	No	Include additional customer sub-resources (comma-separated: addresses, storecredit, attributes, formfields).
`limit`	No	Number of results to return (max 250, default 50).
`name`	No	Filter by customer full name (exact match).
`name_like`	No	Filter by customer name using partial match (substring search).
`page`	No	Page number for pagination (default 1).
`phone`	No	Filter by phone number (exact match).
`registration_ip_address`	No	Filter by registration IP address (exact match).
`sort`	No	Sort field and direction (e.g., "date_created:desc", "last_name:asc", "date_modified:desc").
`store_Hash`	No	Optional store hash. If not provided, uses BIGCOMMERCE_STORE_HASH from environment variables.

TDQS

C2.9/5.0

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 mentions automatic store hash retrieval from environment variables, which is useful context, but lacks details on permissions, rate limits, pagination behavior (beyond parameters), error handling, or what the return format looks like. For a read operation with 19 parameters, this is insufficient.

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 a single, efficient sentence that front-loads key information (getting customers with filtering). It could be slightly more structured by separating the automatic store hash note, but it avoids redundancy and wastes no words.

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 complexity (19 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, error cases, or behavioral traits like pagination limits or authentication needs. The automatic store hash note is helpful, but overall, it falls short for a tool with many parameters and no structured output guidance.

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 19 parameters thoroughly. The description adds minimal value by listing some filter types (email, name, company, phone, customer group, dates, pagination) but doesn't provide additional syntax, format, or usage context beyond what's in the schema. 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 verb ('Get') and resource ('all customers from the BigCommerce API'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_all_orders' or 'get_all_products' beyond mentioning customers specifically, which is implied but not contrasted.

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 mentions 'comprehensive filtering options' and automatic store hash retrieval, but provides no explicit guidance on when to use this tool versus alternatives (e.g., for filtering vs. other customer-related tools). There's no mention of prerequisites, exclusions, or sibling tool comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_all_ordersB

Get all orders from the BigCommerce API. Can filter by customer_id to get products associated with specific customers through their order history. Store hash is automatically retrieved from environment variables.

ParametersJSON Schema

Name	Required	Description
`cart_id`	No	Filter orders by cart ID.
`channel_id`	No	Filter orders by channel ID.
`customer_id`	No	Filter orders by specific customer ID to get products associated with that customer.
`email`	No	Filter orders by customer email address.
`external_order_id`	No	Filter orders by external order ID.
`limit`	No	Number of results to return (default: 50, max: 250).
`max_date_created`	No	Maximum date created for filtering (ISO 8601 format, e.g., 2023-12-31T23:59:59Z).
`max_date_modified`	No	Maximum date modified for filtering (ISO 8601 format, e.g., 2023-12-31T23:59:59Z).
`max_id`	No	Maximum order ID for filtering.
`max_total`	No	Maximum order total amount for filtering.
`min_date_created`	No	Minimum date created for filtering (ISO 8601 format, e.g., 2023-01-01T00:00:00Z).
`min_date_modified`	No	Minimum date modified for filtering (ISO 8601 format, e.g., 2023-01-01T00:00:00Z).
`min_id`	No	Minimum order ID for filtering.
`min_total`	No	Minimum order total amount for filtering.
`page`	No	Page number to return (default: 1).
`payment_method`	No	Filter orders by payment method (e.g., credit_card, paypal, manual).
`sort`	No	Sort field and direction (e.g., date_created:desc, id:asc, total:desc).
`status_id`	No	Filter orders by status ID (e.g., 1=Pending, 7=Awaiting Payment, 11=Awaiting Fulfillment).
`store_Hash`	No	Optional store hash. If not provided, uses BIGCOMMERCE_STORE_HASH from environment variables.

TDQS

B3.2/5.0

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 mentions that store hash is automatically retrieved from environment variables, which is useful context about configuration. However, it doesn't describe critical behavioral traits like whether this is a read-only operation, pagination behavior (implied by limit/page parameters but not explained), rate limits, authentication requirements, or what happens when no filters are applied. For a tool with 19 parameters and 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with three sentences that each serve a purpose: stating the core function, explaining a key filtering use case, and providing implementation detail about store hash. It's front-loaded with the main purpose and avoids unnecessary elaboration. However, the second sentence about customer_id filtering could be more tightly integrated with the first sentence for better flow.

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 (19 parameters, no annotations, no output schema), the description provides a basic but incomplete picture. It covers the core purpose and one filtering scenario but doesn't address the tool's full behavioral context, return format, error conditions, or relationship to sibling tools. The 100% schema coverage helps with parameter understanding, but the description alone doesn't provide enough context for confident agent usage without additional inference from the schema.

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 19 parameters thoroughly. The description adds minimal value beyond the schema by mentioning customer_id filtering specifically and noting that store hash can be auto-retrieved from environment variables. This provides some contextual meaning but doesn't significantly enhance understanding beyond what's already in the parameter descriptions. The baseline of 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.

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 all orders from the BigCommerce API.' It specifies the resource (orders) and the action (get), though it doesn't explicitly differentiate from sibling tools like get_all_customers or get_all_products beyond mentioning different resources. The mention of filtering by customer_id adds some specificity but doesn't fully distinguish it from potential order-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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides implied usage context by mentioning filtering by customer_id to get products associated with specific customers, but it doesn't explicitly state when to use this tool versus alternatives or any prerequisites. The note about store hash being automatically retrieved from environment variables offers some operational guidance, but no explicit when/when-not instructions or sibling tool comparisons are included.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_all_productsC

Get all products from the BigCommerce API. Store hash is automatically retrieved from environment variables.

ParametersJSON Schema

Name	Required	Description	Default
`store_Hash`	No	Optional store hash. If not provided, uses BIGCOMMERCE_STORE_HASH from environment variables.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions automatic retrieval of store hash from environment variables, which is useful context, but doesn't describe important behavioral aspects like pagination, rate limits, authentication requirements, error conditions, or what 'all products' means in practice (e.g., maximum results, filtering options).

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 concise with two sentences that both add value. The first sentence states the core purpose, and the second provides important implementation context about environment variable usage. No wasted words or redundant information.

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 no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (product format, data structure), doesn't mention pagination or result limitations for 'all products,' and provides minimal behavioral context. The agent would struggle to use this tool effectively without additional information.

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 fully documents the single optional parameter. The description adds the context that store hash is automatically retrieved from environment variables when not provided, which provides useful operational context beyond the schema's technical documentation.

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 resource ('all products from the BigCommerce API'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like get_all_customers and get_all_orders, but the resource specificity provides implicit differentiation.

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 sibling tools, prerequisites, or contextual factors that would help an agent decide between get_all_products, get_all_customers, or get_all_orders.

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. Dates show when Glama detected each change.

3 tool updatesv1.0.0Sep 9, 2025
- First observedget_all_customers
- First observedget_all_orders
- First observedget_all_products

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting different BigCommerce resources: customers, orders, and products. There is no overlap in functionality, and the descriptions specify unique filtering capabilities where applicable, making tool selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'get_all_' prefix followed by the resource name (customers, orders, products). This predictable naming scheme enhances readability and usability across the tool set.

Tool Count2/5

With only 3 tools, this server feels under-scoped for a BigCommerce API integration. A typical e-commerce platform requires more operations like creating, updating, or deleting resources, making this set too limited for comprehensive agent workflows.

Completeness2/5

The tool set is severely incomplete, covering only read operations (get_all) for three core resources. There are significant gaps in CRUD coverage—no create, update, or delete tools—which will likely cause agent failures when attempting full e-commerce management tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Regenique Elegance Commerce A
com.regenique-elegance.agents
AI-powered commerce API for luxury skincare shopping. Enables AI agents to search products, browse collections, manage shopping carts, and generate checkout URLs for the Regenique Elegance Shopify store.
E-commerce & Retail App Automation Marketing
2
nanocart-mcp
io.github.ByteBunny-io
Manage your NanoCart store from any AI agent: products, orders, coupons, subscribers, reports.
E-commerce & Retail Marketing
1
feeefapp-mcp
ai.smithery
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
E-commerce & Retail App Automation
2
FanvaultOAuth
io.github.thefanvault
Run storefronts, listings, orders, content, fulfillment, and analytics through AI.
E-commerce & Retail Content Management Systems Data Visualization
2

Related MCP Servers

BareMCP
E-commerce & Retail App Automation Developer Tools
barecommerce-core
A
license
Not graded
quality
D
maintenance
Enables AI assistants to manage BareCommerceCore e-commerce stores through 46 tools covering products, orders, customers, categories, pages, media, webhooks, and analytics. Uses secure OAuth authentication without requiring API keys in chat.
Updated 9 months ago (2025-12-16 18:40 UTC)
22
MIT
commercetools Commerce MCPofficial
E-commerce & Retail Customer Data Platforms App Automation
commercetools
A
license
Not graded
quality
A
maintenance
Enables AI agents to interact with commercetools APIs to manage products, categories, orders, carts, and customer data. It provides a comprehensive set of tools for both read-only and full-access operations through secure authentication methods.
Updated a month ago (2026-08-11 11:05 UTC)
4
MIT
ecommerce-mcp
E-commerce & Retail Marketing
bookknhp
F
license
Not graded
quality
C
maintenance
Enables AI to view and manage e-commerce data such as products, orders, and coupons, and perform actions like updating prices, stock, and generating sales reports.
Updated 4 months ago (2026-05-03 07:46 UTC)
-
mcp-woocommerce
E-commerce & Retail Developer Tools
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables AI agents to interact with WooCommerce stores via the WooCommerce REST API, supporting operations like listing products, orders, and customers.
Updated 11 days ago (2026-08-26 17:49 UTC)
18
MIT

Appeared in Searches

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/etugrand/bigcommerce-api-mcp'

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

BigCommerce MCP Server

✨ Features

🚦 Getting Started

⚙️ Prerequisites

📥 Installation & Setup

🔧 Available Tools

🔗 Client Integration

💬 Claude Desktop

� Cline (VS Code Extension)

🤖 Other MCP Clients

🐳 Docker Deployment

Quick Start

Claude Desktop with Docker

Docker Compose (Production)

🧪 Testing

Local Testing

Postman Integration (Optional)

🛠️ Advanced Usage

Server Modes

Environment Variables

🔍 Tool Examples

Find products associated with a customer

Search customers by email

🤝 Contributing

📄 License

🆘 Support & Questions

🚀 What's Next?

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

BareMCP

commercetools Commerce MCPofficial

ecommerce-mcp

mcp-woocommerce

Appeared in Searches

Latest Blog Posts

MCP directory API