Ecommerce Store Discovery MCP Server

Discover ecommerce stores

discover_ecommerce_stores

Read-only

Find online stores selling a product on Shopify, WooCommerce, or BigCommerce using keywords; each result is confirmed on its own homepage with platform evidence and contact details.

Instructions

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.

Input Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 24, 2026

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.

Deploy Server

Other Tools

discover_ecommerce_storesA