Ecommerce Store Discovery MCP Server
Discovers BigCommerce stores from keyword searches, verifies BigCommerce storefronts, and returns store details such as payment methods, currencies, contact information, and social links.
Searches Google result pages using product keywords and platform footprints to find candidate ecommerce stores, excluding marketplaces, social networks, and reference sites.
Discovers Shopify stores by keyword, confirms the Shopify footprint on each storefront, and returns Shopify-specific data such as product counts along with contact and payment details.
Discovers WooCommerce stores by keyword and confirms WooCommerce marks on store homepages, returning store metadata and contact details.
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., "@Ecommerce Store Discovery MCP ServerFind 25 Shopify stores selling coffee beans with their contact emails"
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.
Ecommerce Store Discovery MCP Server
An MCP server for the Mamba Labs Ecommerce Store Discovery actor on Apify. Give it product keywords and a platform. Each run finds stores through Google, confirms each one on its own homepage, and returns one row per store.
What's Inside
Related MCP server: Commerce MCP Server
What it does
Searches Google with each keyword plus a footprint the platform prints on its stores, and drops marketplaces, social networks, and reference sites.
Reads each candidate's robots.txt and homepage, and returns the store only when the homepage carries the platform's marks, with the evidence and a confidence.
Per store: payment methods, subscription apps, currencies, Shopify product count, Tranco rank band and trend, contact emails, phone, and Instagram, Facebook, and TikTok links from the homepage.
Unconfirmed sites are skipped and not charged.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
Quick start
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-ecommerce-store-discovery": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-ecommerce-store-discovery"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The discover_ecommerce_stores tool appears.
Prerequisites
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as
APIFY_TOKEN. The server lists its tool without a token; a call needs one.
Example prompts
"Find 30 Shopify stores that sell coffee beans and show their product counts and contact emails."
"Which WooCommerce stores in the UK sell dog treats?"
"List BigCommerce stores selling auto parts, with their payment providers."
Tool
discover_ecommerce_stores. One tool. Example arguments:
{
"keywords": ["coffee beans"],
"platform": "shopify",
"max_stores": "25"
}Inputs
Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and booleans are sent as strings.
Input | Type | Description |
| array | What the stores sell. Required |
| string | shopify (default), woocommerce, bigcommerce, or any |
| string | Confirmed stores to return, up to 500. Default 25 |
| string | Google market. Default US |
| string | Word added to every search |
| string | Google interface language. Default en |
| string | true or false. Default true |
| string | true or false. Default true |
| string | true or false. Default false |
| array | Domains to skip |
| string | Cap on Google pages read |
| string | Optional cost cap for the run |
Pricing
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.0055 | $0.005225 | $0.00495 | $0.004675 |
| $0.019 | $0.01805 | $0.0171 | $0.01615 |
| $0.002 | $0.002 | $0.002 | $0.002 |
Unconfirmed, refused, and failed sites are free.
Your keys
The actor needs no key. It reads Google result pages through the Apify Google SERP proxy and the stores' own public pages, and holds no key of any kind. Mamba Labs pays the platform and proxy costs of the run.
Full actor documentation
apify.com/mambalabs/ecommerce-store-discovery
License
MIT. See LICENSE.
Available Tools
1 tooldiscover_ecommerce_storesDiscover ecommerce storesARead-only
Find online stores that sell a product on a given platform (shopify, woocommerce, bigcommerce, or any), with each store confirmed on its own homepage. Give keywords and a platform. One row per store: domain, store_name, platform with platform_confidence and platform_evidence, myshopify_domain, payment_methods, subscription_apps, currencies, product_count (Shopify products feed), Tranco rank band and trend (a rank, not traffic), contact_emails, phone, and Instagram, Facebook, and TikTok links from the homepage, plus the search that found it. Sites that do not show the platform are skipped and not charged. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per confirmed store and per Google result page read.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Two letter country code for the Google market searched. Default US. | |
| keywords | Yes | What the stores sell, for example coffee beans. Up to 50. | |
| language | No | Google interface language. Default en. | |
| platform | No | Store platform to find. any returns stores on any platform the homepage reveals. Default shopify. | |
| max_stores | No | Stop after this many confirmed stores, up to 500. Each is one store-found event. Default 25. | |
| location_term | No | Optional word added to every search, such as Texas or Australia. | |
| max_charge_usd | No | Optional. The run stops before any charge that would take it over this amount. | |
| exclude_domains | No | Domains to skip, for example stores already in your CRM. | |
| max_search_pages | No | Cap on Google result pages read; each is one search-page event. Empty or 0: set from max_stores. | |
| include_unconfirmed | No | Also return, free, sites whose homepage did not show the platform. Default false. | |
| include_traffic_rank | No | Add the Tranco top sites rank (not a visit count). Default true. | |
| include_product_count | No | Read the Shopify public products feed for a product count. Default true. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and open-world, and the description adds substantial context beyond them: APIFY_TOKEN requirement, per-confirmed-store and per-Google-page billing, that unconfirmed sites are skipped and not charged, and that failed runs return an error with a run ID. It also pre-empts misinterpretation by noting Tranco is a rank, not traffic.
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?
Purpose and inputs are front-loaded, then costs and failure behavior, with the field list embedded mid-paragraph. The enumeration of returned columns is long but justified because no output schema exists; a little tightening of the field run-on would help.
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 12 parameters and no output schema, the description carries the return-shape and cost burden well by listing output fields, billing events, and error behavior. What remains unstated is pagination/result limits and how much output a single call returns relative to max_stores.
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%, so the baseline is 3; the description still adds value by naming the platform choices, clarifying that keywords are product terms, and flagging that rank output is a rank rather than a visit count. It does not add much to the numeric or enum parameters the schema already explains.
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 ("find online stores that sell a product") plus the confirmation mechanism ("each store confirmed on its own homepage") and the platform scope. An agent knows exactly what it gets back, including the platform-confidence evidence.
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?
Gives the calling recipe ("Give keywords and a platform") and explains key defaults such as platform=shopify and include_unconfirmed=false, plus that skipped sites are free. It lacks explicit when-not-to-use guidance, but with no sibling tools there is little alternative to route against.
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 tool update
v1.0.0- First observed
discover_ecommerce_stores
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of selecting the wrong tool or confusing overlapping purposes. Its purpose is clearly stated as ecommerce store discovery.
The single tool name follows a clear snake_case verb_noun pattern: discover_ecommerce_stores. Although there is only one name, it is descriptive and internally consistent.
A single tool is thin for an MCP server, even one narrowly focused on store discovery. The tool itself is broad and complex, but the surface offers no separate lookup, filtering, or result-management operations.
The discovery operation returns rich store-level details, platform evidence, contact data, social links, ranking context, and error run IDs. Minor gaps remain, such as no follow-up lookup by domain or pagination/result-management tools, but the core discovery workflow is covered.
Maintenance
Related MCP Connectors
Google Shopping results for any product search and country: price, original price and discount, store, delivery, returns, rating and review count, about 50 products per search. Runs on Apify, $1 per 1,000 products.
Search Shopify stores, enrich domains, and reveal approved contact channels.
Search products from independent Shopify stores: prices, merchant offers and buy links.
Product search for AI agents: Amazon + Shopify, cart-to-checkout buy path. Pay-per-call, no API key.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables querying the Apify Store to retrieve structured data on public Actors including pricing, usage trends, ratings, and categories. Integrates with AI agents for market research and competitor tracking.-
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to browse product catalogs, search products with filters, and initiate checkouts, generating order summaries and checkout URLs.-
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to search products across Amazon and live Shopify storefronts, vet merchants, build carts, and obtain checkout URLs via a pay-per-call API with no API key or signup.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to discover new and pre-launch Shopify stores from public CT logs and RDAP data, and to check any list of domains for Shopify usage with registration dates and store metadata.MIT