Skip to main content
Glama
mambalabsdev

Ecommerce Store Discovery MCP Server

Ecommerce Store Discovery MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

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

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

keywords

array

What the stores sell. Required

platform

string

shopify (default), woocommerce, bigcommerce, or any

max_stores

string

Confirmed stores to return, up to 500. Default 25

country

string

Google market. Default US

location_term

string

Word added to every search

language

string

Google interface language. Default en

include_product_count

string

true or false. Default true

include_traffic_rank

string

true or false. Default true

include_unconfirmed

string

true or false. Default false

exclude_domains

array

Domains to skip

max_search_pages

string

Cap on Google pages read

max_charge_usd

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

store-found, one confirmed store

$0.0055

$0.005225

$0.00495

$0.004675

search-page, one Google result page read

$0.019

$0.01805

$0.0171

$0.01615

apify-actor-start, per run start

$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 tool
discover_ecommerce_storesDiscover ecommerce storesA
Read-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.

NameRequiredDescriptionDefault
countryNoTwo letter country code for the Google market searched. Default US.
keywordsYesWhat the stores sell, for example coffee beans. Up to 50.
languageNoGoogle interface language. Default en.
platformNoStore platform to find. any returns stores on any platform the homepage reveals. Default shopify.
max_storesNoStop after this many confirmed stores, up to 500. Each is one store-found event. Default 25.
location_termNoOptional word added to every search, such as Texas or Australia.
max_charge_usdNoOptional. The run stops before any charge that would take it over this amount.
exclude_domainsNoDomains to skip, for example stores already in your CRM.
max_search_pagesNoCap on Google result pages read; each is one search-page event. Empty or 0: set from max_stores.
include_unconfirmedNoAlso return, free, sites whose homepage did not show the platform. Default false.
include_traffic_rankNoAdd the Tranco top sites rank (not a visit count). Default true.
include_product_countNoRead the Shopify public products feed for a product count. Default true.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.0.0
    • First observeddiscover_ecommerce_stores

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers