Provides read-only access to a WooCommerce merchant store, exposing tools to search and retrieve orders by status and date range, fetch order details with line items, search and retrieve products from the catalog, and inspect inventory levels with low-stock and out-of-stock filtering. Customer PII is stripped and all operations are read-only, with built-in rate-limit handling and bounded pagination.
Click on "Deploy 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., "@Cartix which pending orders have been waiting more than 24 hours?"
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.
Cartix is a secure, read-only Model Context Protocol (MCP) connector that enables an AI agent to access, inspect, and reason over merchant commerce data stored in WooCommerce.
Built for the Razorpay Forward-Deployed Engineer, Agent Studio assessment.
Related MCP server: woocommerce-mcp-server
Merchants store critical operational data across WooCommerce (orders, fulfillment statuses, customer purchases, catalog pricing, and inventory levels). Normally, store managers must manually navigate dashboards, execute multiple searches, calculate order delays, and inspect stock logs to answer routine questions:
"Which pending orders have been waiting for more than 24 hours?"
"Which products are out of stock or running low?"
"Are any pending orders affected by products that are currently out of stock?"
AI agents cannot reliably access raw WooCommerce REST APIs directly because:
Exposing raw API credentials to an LLM context creates critical security vulnerabilities.
Raw merchant payloads contain sensitive customer PII (billing addresses, phone numbers, customer emails) and massive unstructured payloads.
Upstream merchant APIs enforce strict rate limits (HTTP 429), pagination boundaries, and transient network errors that LLMs cannot manage autonomously.
Cartix serves as the hardened, reliable bridge between the AI agent and WooCommerce. It abstracts store complexity into clean, typed MCP tool primitives, enforces read-only access, handles upstream rate-limiting with exponential backoff and jitter, redacts secrets, strips PII, and bounds pagination.
┌─────────────────────────┐
│ Merchant / User │
└────────────┬────────────┘
│ Natural Language
▼
┌─────────────────────────┐
│ AI Agent │
│ LLM + MCP Client │
└────────────┬────────────┘
│
│ MCP Protocol (Tools & Schemas)
▼
┌───────────────────────────────────────────────────────────┐
│ CARTIX │
│ MCP Server │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ MCP Tools │ │
│ │ search_orders get_order search_products │ │
│ │ get_product get_inventory │ │
│ └──────────────────────────┬──────────────────────────┘ │
│ │ │
│ ┌──────────────────────────▼──────────────────────────┐ │
│ │ Service Layer │ │
│ │ OrderService ProductService InventoryService │ │
│ │ Validation Normalization Data Minimization│ │
│ └──────────────────────────┬──────────────────────────┘ │
│ │ │
│ ┌──────────────────────────▼──────────────────────────┐ │
│ │ Reliability Layer │ │
│ │ Exponential Backoff + Jitter • 429 Retry-After │ │
│ │ Token-Bucket Rate Limiter • Bounded Pagination │ │
│ │ Structured CartixError • Safe Logging + RequestIDs │ │
│ └──────────────────────────┬──────────────────────────┘ │
│ │ │
│ ┌──────────────────────────▼──────────────────────────┐ │
│ │ WooCommerce Client │ │
│ │ HTTPS Basic Auth • Secret Redaction • Timeouts │ │
│ └──────────────────────────┬──────────────────────────┘ │
└─────────────────────────────┼─────────────────────────────┘
│ HTTPS / REST (Read-Only)
▼
┌─────────────────────────┐
│ WooCommerce │
│ Merchant Store │
└─────────────────────────┘Responsibility | AI Agent | Cartix MCP Connector | WooCommerce |
Natural Language Understanding | ✅ Primary | ❌ No | ❌ No |
Tool Selection & Chaining | ✅ Primary | ❌ No | ❌ No |
Reasoning Over Timestamps & Stock | ✅ Primary | ❌ No | ❌ No |
Store Authentication & Keys | ❌ Never | ✅ Server-side only | ❌ No |
Rate-Limit Backoff & Retries | ❌ No | ✅ Automatic (429 handling) | ❌ No |
Data Normalization & PII Removal | ❌ No | ✅ Strips PII, compacts schemas | ❌ No |
Source of Truth for Data | ❌ No | ❌ No | ✅ Primary |
Cartix exposes exactly 5 focused, read-only MCP tools:
search_ordersPurpose: Search and filter orders by status and date range.
Inputs:
status (string, optional): Filter by status (pending, processing, completed, on-hold, failed, cancelled).
date_from (ISO 8601 string, optional): Inclusive start datetime.
date_to (ISO 8601 string, optional): Inclusive end datetime.
page (integer, default: 1): Page number.
limit (integer, 1-100, default: 20): Maximum records to return.
Output: Normalized order summaries with total amount, item count, timestamps, and bounded pagination metadata.
get_orderPurpose: Retrieve full details for a specific order by ID.
Inputs:
order_id (positive integer, required): WooCommerce order ID.
Output: Complete normalized order containing line items (product ID, name, quantity, unit price, line total), status, and customer notes. Returns NOT_FOUND if invalid.
search_productsPurpose: Search product catalog by text keyword or SKU.
Inputs:
query (string, optional): Keyword to match against titles, descriptions, or SKUs.
page (integer, default: 1): Page number.
limit (integer, 1-100, default: 20): Page size limit.
Output: Normalized product objects (ID, name, SKU, price, stock status, stock quantity, clean description without HTML).
get_productPurpose: Retrieve details for a specific product by ID.
Inputs:
product_id (positive integer, required): WooCommerce product ID.
Output: Normalized product record with pricing and stock details.
get_inventoryPurpose: Retrieve store inventory with deterministic low-stock and out-of-stock filtering.
Inputs:
low_stock_only (boolean, default: false): When true, filters for items with stock_status === 'outofstock' or managed stock_quantity <= 5.
page (integer, default: 1): Page number.
limit (integer, 1-100, default: 20): Page size limit.
Output: Inventory records with is_low_stock indicators.
✓ Search orders by status and date filters
✓ Retrieve specific order line items and statuses
✓ Search product catalog and inspect prices
✓ Query inventory levels and identify stockouts
✗ Create, modify, cancel, or refund orders
✗ Create, edit, or delete products
✗ Modify stock quantities or prices
✗ Access customer personal information (billing address, phone, email, customer IP are stripped)
✗ Access WooCommerce credentials, API keys, or raw authentication headers
All loggers and error formatters scrub sensitive credential patterns (ck_..., cs_..., Basic ..., Bearer ...) before output.
Node.js: v20.0.0 or higher
npm: v10.0.0 or higher
WooCommerce Store: A WooCommerce store or test sandbox with REST API credentials
# Clone the repository
git clone https://github.com/merchant-tools/cartix.git
cd cartix
# Install dependencies
npm install
# Copy environment template
cp .env.example .envLog in to your WordPress admin dashboard (https://your-store.com/wp-admin).
Verify Settings → Permalinks is set to Post name (pretty permalinks are required for WooCommerce REST API).
Navigate to WooCommerce → Settings → Advanced → REST API.
Click Add Key:
Description: Cartix Read-Only Connector
Permissions: Select Read
Copy the generated credentials into your local .env:
WOOCOMMERCE_URL=https://your-store.com
WOOCOMMERCE_CONSUMER_KEY=ck_xxxxxxxxxxxxxxxxxxxxxxxx
WOOCOMMERCE_CONSUMER_SECRET=cs_xxxxxxxxxxxxxxxxxxxxxxxx
PORT=3000
NODE_ENV=developmentCartix includes an automated seeder (scripts/seed.ts) that populates test stores with a realistic commerce dataset:
20 Products: 10 in-stock, 5 low-stock, 5 out-of-stock items across multiple categories.
50 Orders: Distributed across varied statuses (pending, processing, completed, on-hold, failed, cancelled) and timestamps (recent, > 24 hours old, > 48 hours old, > 72 hours old) referencing seeded products.
# Run seeder (requires Read/Write key in .env or WOOCOMMERCE_SEED_CONSUMER_KEY)
npm run seed# Start in development mode
npm run dev
# Start compiled production server (Stdio transport)
npm startAdd Cartix to your Claude Desktop configuration (claude_desktop_config.json):
{
"mcpServers": {
"cartix": {
"command": "node",
"args": ["/path/to/cartix/dist/src/index.js"],
"env": {
"WOOCOMMERCE_URL": "https://your-store.com",
"WOOCOMMERCE_CONSUMER_KEY": "ck_xxxxxxxxxxxxxxxxxxxxxxxx",
"WOOCOMMERCE_CONSUMER_SECRET": "cs_xxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}Connect using standard stdio transport pointing to node dist/src/index.js.
Cartix includes an AI Agent demo (demo/agent.ts) that connects to the Cartix MCP server, dynamically discovers tools, translates schemas to LLM function calls, and executes reasoning loops.
Runs all 6 core assessment scenarios in sequence:
npm run demo -- --allInteract with your live store via conversational natural language:
npm run demo(Note: If LLM_API_KEY is configured in .env, the agent connects to Google Gemini; otherwise, it operates using an intelligent local reasoning engine for offline/CI verification).
Scenario | Natural Language Prompt | Cartix Tool Chain | Agent Reasoning |
1. Pending Orders | "Show me all pending orders." |
| Summarizes count, total amounts, and IDs |
2. Delayed Orders | "Which pending orders have been waiting for more than 24 hours?" |
| Computes timestamp delta against current time ( |
3. Inventory Alerts | "Which products are out of stock or low in stock?" |
| Groups products into out-of-stock alerts and low-stock warnings |
4. Order Details | "Tell me about order #1004." |
| Extracts line items, quantities, subtotal, and fulfillment state |
5. Product Search | "Find products containing keyboard." |
| Returns matching catalog entries, prices, and stock availability |
6. Multi-Tool Reasoning | "Are any pending orders affected by products that are out of stock?" |
| Cross-references order line items with out-of-stock product IDs |
Cartix maintains an extensive automated test suite covering unit, integration, and failure modes.
# Run all 60 tests
npm test
# Run tests with coverage
npm run test:coverage
# Run TypeScript typecheck
npm run typecheck
# Verify build
npm run buildUnit Tests: Input validation, Zod schemas, order/product/inventory normalizers, error serialization.
Reliability Tests: 429 rate limit backoff, Retry-After header extraction, exponential jitter scaling, 5xx server retry, fast-fail on 401/403/404.
Integration Tests: In-memory MCP client-server pair, tool discovery (tools/list), dynamic execution (tools/call), structured error responses (isError: true).
Failure Tests: Malformed ISO dates, non-integer IDs, empty searches, upstream disconnects (ECONNREFUSED), 503 errors, and secret leakage audits.
docker build -t cartix:latest .docker run -d \
-p 3000:3000 \
-e WOOCOMMERCE_URL="https://your-store.com" \
-e WOOCOMMERCE_CONSUMER_KEY="ck_xxxxxxxxxxxx" \
-e WOOCOMMERCE_CONSUMER_SECRET="cs_xxxxxxxxxxxx" \
cartix:latestCartix includes an interactive static documentation website and 3D architectural pipeline visualizer.
Website Location: /website (contains standalone HTML, CSS, Vanilla JS, and interactive canvas visualizer; no frontend frameworks or build steps required).
GitHub Pages Source: Configured as GitHub Actions in repository Settings → Pages.
How Deployment Works: $$\text{Push to } \texttt{main} \longrightarrow \text{GitHub Actions } (\texttt{.github/workflows/deploy-pages.yml}) \longrightarrow \text{Uploads } \texttt{/website} \longrightarrow \text{Deploys to GitHub Pages}$$
Expected Project URL:
https://<username>.github.io/Cartix/ (or https://<username>.github.io/cartix/)
All static assets, stylesheets, scripts, and internal links in /website use root-agnostic relative paths to support subpath deployment seamlessly.
Read-Only Scope: Cartix intentionally does not perform write, refund, order modification, or product update operations for this assessment.
Deterministic Low-Stock: A product is classified as low stock if stock_status === 'outofstock' or managed stock_quantity <= (low_stock_amount || 5).
Authentication: Uses WooCommerce REST API v3 Basic Authentication over HTTPS.
Pagination Ceiling: Results per tool request are bounded to a maximum of 100 items (MAX_PAGE_SIZE=100) to prevent LLM context exhaustion.
For production multi-tenant deployments, Cartix can evolve to include:
OAuth 2.0 / WooCommerce App Authorization: Enabling zero-credential one-click merchant onboarding.
Webhook Ingestion: Real-time push updates for order.created and product.out_of_stock.
Multi-Store Aggregation: Single agent interface across multiple regional WooCommerce stores.
Write Actions with Human-in-the-Loop Gating: Exposing refund and status update tools with explicit approval tokens.
Retrieve inventory levels and stock status for products in the WooCommerce store. Supports filtering for low-stock and out-of-stock items (deterministic low stock threshold <= 5).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| limit | No | Maximum number of inventory items to return (1-100). | |
| low_stock_only | No | When true, only returns products that are out of stock or have stock quantity below or equal to their low stock threshold (default threshold: <= 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It conveys the read nature of the call and usefully discloses the deterministic low-stock threshold, but omits permissions/auth requirements, pagination behavior beyond what the schema says, and any side effects or rate limits.
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?
Two tight sentences with the core action front-loaded and the filtering capability immediately after. No filler, though the parenthetical threshold repeats schema content.
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 read-only list tool with three fully documented parameters and no output schema, the description is minimally adequate: it explains what is fetched and the filtering option. It lacks detail on the shape/ordering of returned inventory data and does not compensate for the absence of annotations.
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 100%, so the schema already documents page, limit, and low_stock_only thoroughly. The description restates the threshold detail ('<= 5') that the low_stock_only schema field already contains, adding no new parameter meaning.
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 specific verb ('Retrieve') and resource ('inventory levels and stock status for products') scoped to the WooCommerce store, which is clearly distinguishable from the order- and product-centric siblings. It does not explicitly name an alternative, but the purpose is unambiguous.
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 by noting support for filtering low-stock and out-of-stock items, which hints at the relevant scenario. However, it never states when to use this tool versus search_products or get_product, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve complete normalized details for a specific WooCommerce order by its integer ID, including line items, prices, status, and customer notes. Returns NOT_FOUND error if order does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The unique positive integer ID of the WooCommerce order to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the NOT_FOUND failure mode for a missing order, which is real behavioral context, but says nothing about authentication requirements, rate limits, or whether the read is side-effect free.
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?
Two tight sentences, front-loaded with the core action and payload before the error caveat. No filler or redundancy; every clause adds information.
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 output schema, the description responsibly summarizes the return payload (line items, prices, status, customer notes) and the error case, which is enough for a single-param read tool. Only auth/permission context is absent, a minor gap given the simple surface.
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 100% and the single order_id parameter is fully documented in the schema with type and minimum. The description only restates 'integer ID' and adds no format, range, or lookup nuance beyond the schema, so baseline 3 applies.
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 (Retrieve) and resource (WooCommerce order), scoped by integer ID, and enumerates the payload (line items, prices, status, customer notes). This clearly separates it from search_orders and get_product without needing to open any schema.
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 'by its integer ID' framing implies the when-to-use case (you already have an ID) versus the search sibling, but the tool never states this explicitly or names search_orders as the alternative when only a query is available. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full normalized details for a specific WooCommerce product by its integer ID, including SKU, price, sale price, stock quantity, and stock status. Returns NOT_FOUND if product does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The unique positive integer ID of the WooCommerce product to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose the returned field set, the normalization behavior, and the NOT_FOUND error outcome, which is genuine context, but it never states that this is a read-only operation or what permissions are required.
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?
Two sentences, front-loaded with the operation and scope, and the second sentence delivers the error case without padding. The field enumeration is slightly long but each item is informative rather than filler.
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?
There is no output schema, so the description correctly compensates by naming the fields returned and the failure mode. It is nearly complete for a single-parameter read tool, missing only permission/read-only framing.
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 100%, with the product_id parameter fully documented including type and minimum, so the schema does the heavy lifting. The description only restates 'integer ID' and adds no format or edge-case detail beyond the schema baseline.
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 specific verb (Retrieve) and resource (WooCommerce product) and enumerates the returned data (SKU, price, sale price, stock quantity, status). It does not explicitly differentiate itself from siblings like get_order or search_products, so an agent must infer the boundary from context.
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 its integer ID' implicitly tells the agent this is the direct-lookup path versus the sibling search_products, but no alternative is named and no precondition is spelled out. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter WooCommerce merchant orders by status and date range. Returns compact, normalized order summaries with total amounts, item counts, status, and pagination metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| limit | No | Maximum number of orders to return (1-100). | |
| status | No | Optional WooCommerce order status filter (e.g., "pending", "processing", "completed", "on-hold", "failed", "cancelled"). | |
| date_to | No | Optional inclusive end datetime in ISO 8601 format (e.g., "2026-10-02T23:59:59Z"). | |
| date_from | No | Optional inclusive start datetime in ISO 8601 format (e.g., "2026-10-01T00:00:00Z"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the return shape ('compact, normalized order summaries with total amounts, item counts, status, and pagination metadata'), which is useful behavioral context, but says nothing about permissions, rate limits, or result ordering for a read/mutation boundary that is otherwise unstated.
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?
Two sentences, zero waste: the first front-loads purpose and filters, the second covers the return payload. Nothing redundant.
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 zero-required-parameter search tool with no output schema, the description compensates by listing the returned fields and noting pagination metadata, so an agent knows what to expect. It is nearly complete, with only ordering/sorting behavior left unspecified.
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 100%, so every parameter (page, limit, status, date_from, date_to) is already documented with defaults, bounds, and ISO 8601 format. The description adds no parameter-level detail beyond restating that status and dates are filters, so baseline 3 applies.
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 gives a specific verb and resource ('Search and filter WooCommerce merchant orders') plus the filtering dimensions (status, date range), so an agent can tell this is a query tool rather than a single-record fetch. It does not explicitly name sibling tools like get_order, so distinction relies on inference from the verb.
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 mention of status and date-range filtering implies when the tool is appropriate (browsing orders across a period), but there is no explicit guidance on when to use this versus get_order for a known ID, nor any stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the WooCommerce product catalog by text query or SKU. Returns normalized products including pricing, stock quantity, stock status, and pagination metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| limit | No | Maximum number of products to return (1-100). | |
| query | No | Optional search keyword or text to match against product titles, descriptions, or SKUs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose the return payload (pricing, stock quantity, stock status, pagination metadata), which usefully signals a read-only, paginated operation. It says nothing about permissions, rate limits, or what happens when the optional query is omitted, so key behavioral context is missing.
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?
Two tightly written sentences: purpose first, return payload second. Zero filler and the most decision-relevant information is front-loaded.
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 read-only search tool with three optional, well-documented parameters and no output schema, the description covers purpose, lookup modes, and returned fields adequately. The one gap is that it does not clarify behavior when the optional query is absent, which matters for callers deciding whether to pass a query at all.
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 100%, so page, limit, and query are already fully documented with ranges and defaults; baseline is 3. The description reinforces the query semantics (titles, descriptions, SKUs) and pagination, but adds no syntax or format detail beyond the schema.
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 specific verb and resource (search the WooCommerce product catalog) plus the lookup modes (text query or SKU), which clearly separates it from a single-item getter like get_product. It does not explicitly name a sibling or contrast its role against search_orders, so it falls short of full sibling differentiation.
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 'search … by text query or SKU', which signals the retrieval scenario, but the description never states when to prefer this over get_product or get_inventory, nor any exclusions or prerequisites. No explicit when/when-not guidance is present.
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.
v0.1.0get_inventoryget_orderget_productsearch_orderssearch_productsScored across 5 tools
search_orders vs get_order and search_products vs get_product are cleanly separated by search-vs-fetch-by-ID intent. get_inventory overlaps somewhat with get_product since both expose stock quantity and status, but its cross-product filtering purpose (low/out-of-stock) keeps it distinguishable.
Every tool follows a strict verb_noun pattern: search_orders, get_order, search_products, get_product, get_inventory. The search/get verbs are used consistently and predictably across resource types.
Five tools is well-scoped and each earns its place for a read-oriented WooCommerce query server. It sits slightly lean, leaving little room for customer or category lookups, but nothing is redundant or bloated.
The read surface is solid for orders, products, and inventory, but there is no customer lookup and no write/lifecycle operations (order status updates, product edits, creation). If the server is strictly read-only this is acceptable, but as a WooCommerce merchant surface it has notable gaps.
Connect AI to store orders, products and inventory with scoped access and human approvals.
Manage WordPress blogs and WooCommerce shops from Claude, ChatGPT, Cursor and other MCP apps.
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
MerchantFlow is a hosted, read-only ecommerce analytics MCP server for Shopify and WooCommerce. It gives AI assistants tenant-scoped access to revenue, profit and loss, product and SKU profitability, COGS coverage, fulfillment costs, advertising spend, ROAS, marketing performance, cohorts, LTV, and business valuation across connected commerce and marketing platforms. Connect with OAuth over Streamable HTTP. No local server installation is required.
