Detects the ecommerce platform, payment stack, and catalog profile behind a storefront, returning one flat Clay-ready JSON row.
Identify the ecommerce platform a storefront runs on (Shopify, WooCommerce, Magento, BigCommerce, Salesforce Commerce, Squarespace, Wix, PrestaShop, or commercetools), with confidence and evidence.
Detect loaded payment providers, plus subscription and marketplace apps.
Estimate catalog size from the Shopify products endpoint or the sitemap (optional).
Report currencies and shipping destinations, plus coverage and fetch status for the row.
Read public cart pages to catch payment/BNPL providers that only load there (optional).
Escalate blocked reads (403/429) once via a residential exit, or fail fast (optional).
Cache successful lookups for seven days or force a fresh fetch (optional).
Use company_name with the domain to reduce wrong matches.
Qualify ecommerce accounts by platform or segment store lists by catalog size and payment stack before outreach.
Requires an APIFY_TOKEN; each call consumes Apify credits.
Detects whether a storefront runs on BigCommerce and reports platform confidence and evidence.
Detects whether a storefront runs on PrestaShop and reports platform confidence and evidence.
Detects whether a storefront runs on Salesforce Commerce and reports platform confidence and evidence.
Detects whether a storefront runs on Shopify, reports platform confidence and evidence, and can estimate product count from the Shopify products endpoint.
Detects whether a storefront runs on Squarespace and reports platform confidence and evidence.
Detects whether a storefront runs on Wix and reports platform confidence and evidence.
Detects whether a storefront runs on WooCommerce and reports platform confidence and evidence.
An MCP server that detects the ecommerce platform, payment providers and catalog size behind a storefront. It wraps the Mamba Labs Ecommerce Platform Profiler actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-company-contact-details-extractor
Give it a company domain and it reads the storefront and returns which ecommerce platform it runs on, which payment providers it loads, whether it sells subscriptions, roughly how many products it lists, and which currencies and shipping destinations it takes. One flat row per company.
Detected platforms include Shopify, WooCommerce, Magento, BigCommerce, Salesforce Commerce, Squarespace, Wix, PrestaShop and commercetools. Reads are static: the homepage, the sitemap, and optionally the public cart page. No browser is used, so a storefront that reveals its platform only after JavaScript runs is reported as not_extractable rather than labeled with the nearest guess. Confidence follows the kind of evidence, so a vendor header is high and a substring in the HTML is low.
All of the detection runs on Apify. This package is a thin client that calls the actor and hands back the result unchanged.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-ecommerce-platform-profiler": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-ecommerce-platform-profiler"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The profile_ecommerce_platform tool will be available.
Node.js 18 or newer
An Apify account with an API token
"What ecommerce platform does allbirds.com run on?"
"Profile gymshark.com and include the payment providers loaded on the cart page."
"Does this storefront sell subscriptions, and roughly how many products does it list?"
"Check the platform for this domain but fail fast if the site blocks us."
company_domain (optional): bare company domain, for example allbirds.com. This is the storefront that gets read, and it is the join key against every other actor in the fleet.
company_name (optional but strongly recommended): what the identity gate checks a discovered record against, so supplying it is the cheapest way to reduce wrong matches.
includeProductCount (optional): when true (the default) the catalog size is estimated, from the Shopify products endpoint where the store is Shopify and from the sitemap otherwise. It costs one or two extra requests.
includePaymentProviders (optional): when true (the default) the payment provider scripts loaded on the storefront are detected. Providers that load only inside a real checkout are invisible from the homepage, which is why checkCheckout exists.
checkCheckout (optional): when true the public cart page is also read, because several payment and buy now pay later providers load there and not on the homepage. This never adds an item, never starts a checkout and never submits anything. It is a plain read of a public URL and costs one extra request.
escalateOnBlock (optional): when true (the default) a storefront that answers 403 or 429 is retried once from a residential exit, because a bot challenge on a first read is common. Set false to fail fast and cheap.
skipCache (optional): when false (the default) a successful lookup is cached for seven days and reused. Set true to force a fresh fetch.
max_charge_usd (optional): a cost cap in USD for this run. The actor stops before an item that could take its charges past this amount. Omit it to rely on the maximum cost per run set in Apify.
The tool returns the actor's flat JSON row for the company, with 22 snake_case fields and no nested objects. platform_confidence and platform_evidence travel with the detection rather than a bare label, coverage shows how much of the row was filled, and fetch_status says whether the read succeeded. See the Apify Store page for the full output schema.
{
"degraded": false,
"degradation_reason": null,
"company_domain": "allbirds.com",
"company_name": "Allbirds",
"ecommerce_platform": "shopify",
"platform_confidence": "high",
"platform_evidence": "header",
"platforms_all": "shopify",
"payment_providers": "apple_pay",
"has_subscriptions": false,
"subscription_apps": null,
"has_marketplace": false,
"product_count_estimate": 250,
"product_count_source": "products_json",
"product_count_exact": false,
"currencies": null,
"ships_to": null,
"pages_read": 2,
"escalated": false,
"coverage": 0.71,
"fetch_status": "ok",
"run_date": "2026-08-22T19:23:53.897Z"
}Identifies the ecommerce platform a storefront runs on
Payment providers, subscription apps and marketplace apps
Catalog size estimate, currencies and shipping destinations
Static homepage and sitemap reads only, no browser
Confidence and evidence recorded per detection, not a bare label
Coverage reported per row, so a thin read is visible
22 flat snake_case fields, one row per company
Price per event on the Apify FREE plan, from the live pricing record; paid Apify plans pay less per event.
Event | Price (USD) |
Actor Start ( | 0.00005 |
Company checked ( | 0.0035 |
Platform detected ( | 0.003 |
Product count estimated ( | 0.0025 |
This server is a thin client and holds no detection logic. For the complete input and output reference, pricing, and run history, see the Apify Store page:
https://apify.com/mambalabs/ecommerce-platform-profiler
This server is one of the Mamba Labs GTM Suite MCP servers. Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything. The actor behind this server is the Ecommerce Platform Profiler, immutable Apify actor ID 5G2NeYjBbQTjaTn9L.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
Detect which ecommerce platform a storefront runs on (Shopify, WooCommerce, Magento, BigCommerce, Salesforce Commerce, Squarespace, Wix, PrestaShop or commercetools), plus its payment providers, subscription and marketplace apps, an estimated catalogue size, currencies and shipping destinations. Returns one flat Clay ready row. Static homepage and sitemap reads only, no browser, so a storefront that reveals its platform only after JavaScript runs is reported as not_extractable rather than labelled with the nearest guess. Confidence follows the KIND of evidence: a vendor header is high, a substring in the HTML is low. Use it to qualify ecommerce accounts by platform before outreach, or to segment a store list by catalogue size and payment stack. Pass company_name with the domain to cut wrong matches. Requires an APIFY_TOKEN and consumes Apify credits per call.
| Name | Required | Description | Default |
|---|---|---|---|
| skipCache | No | When false (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set true to force a fresh fetch. | |
| company_name | No | Optional but strongly recommended. It is what the identity gate checks a discovered record against, so supplying it is the single cheapest way to reduce wrong matches. | |
| checkCheckout | No | When true the public cart page is also read, because several payment and buy now pay later providers load there and not on the homepage. This never adds an item, never starts a checkout and never submits anything: it is a plain read of a public URL. Costs one extra request. | |
| company_domain | No | Bare company domain, for example allbirds.com. This is the storefront that gets read, and it is the join key against every other actor in the fleet including the Pinterest brand presence mapper. | |
| escalateOnBlock | No | When true (default) a storefront that answers 403 or 429 is retried once from a residential exit, because a bot challenge on a first read is common and one retry clears a fair share of them. Set false to fail fast and cheap. | |
| includeProductCount | No | When true (default) the catalogue size is estimated, from the Shopify products endpoint where the store is Shopify and from the sitemap otherwise. It costs one or two extra requests. | |
| includePaymentProviders | No | When true (default) the payment provider scripts loaded on the storefront are detected. Providers that load only inside a real checkout are invisible from the homepage, which is why checkCheckout exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, the description discloses the extraction method ('static homepage and sitemap reads only, no browser'), the failure mode ('not_extractable rather than labelled with the nearest guess'), the confidence model ('vendor header is high, a substring in the HTML is low'), plus token and credit costs. This is exactly the extra context annotations cannot carry.
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?
Front-loaded with platforms and outputs, then progressively narrows to caveats, usage, and costs. Dense but nearly every clause carries signal; the combined platform list and attribute list make the opening sentence long.
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?
No output schema exists, and the description compensates by naming the return shape ('one flat Clay ready row') and the degraded-case value ('not_extractable'). Behavior, requirements, and confidence semantics are all covered for a zero-required-parameter tool.
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% and the schema already explains every parameter, including skipCache caching, checkCheckout, and escalateOnBlock defaults. The description adds only a redundant reminder to pass company_name, which the schema itself calls 'strongly recommended' and 'the single cheapest way to reduce wrong matches.' Baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ('Detect which ecommerce platform a storefront runs on'), enumerates the nine platforms detected, and names the full set of derived attributes (payment providers, apps, catalogue size, currencies, shipping). An agent knows exactly what this returns without opening the 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?
Explicitly states the two intended jobs: 'qualify ecommerce accounts by platform before outreach, or segment a store list by catalogue size and payment stack.' It also names a precondition ('Pass company_name with the domain to cut wrong matches') and a cost/credential requirement, leaving nothing to inference.
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.
v1.1.1profile_ecommerce_platform6 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / checkCheckout / descriptionPrevious value: -"When \"true\" the public cart page is also read, because several payment and buy now pay later providers load there and not on the homepage. This never adds an item, never starts a checkout and never submits anything: it is a plain read of a public URL. Costs one extra request. Sent as a string for Clay compatibility."New value: +"When true the public cart page is also read, because several payment and buy now pay later providers load there and not on the homepage. This never adds an item, never starts a checkout and never submits anything: it is a plain read of a public URL. Costs one extra request."Input schema / properties / escalateOnBlock / descriptionPrevious value: -"When \"true\" (default) a storefront that answers 403 or 429 is retried once from a residential exit, because a bot challenge on a first read is common and one retry clears a fair share of them. Set \"false\" to fail fast and cheap. Sent as a string for Clay compatibility."New value: +"When true (default) a storefront that answers 403 or 429 is retried once from a residential exit, because a bot challenge on a first read is common and one retry clears a fair share of them. Set false to fail fast and cheap."Input schema / properties / includePaymentProviders / descriptionPrevious value: -"When \"true\" (default) the payment provider scripts loaded on the storefront are detected. Providers that load only inside a real checkout are invisible from the homepage, which is why checkCheckout exists. Sent as a string for Clay compatibility."New value: +"When true (default) the payment provider scripts loaded on the storefront are detected. Providers that load only inside a real checkout are invisible from the homepage, which is why checkCheckout exists."Input schema / properties / includeProductCount / descriptionPrevious value: -"When \"true\" (default) the catalogue size is estimated, from the Shopify products endpoint where the store is Shopify and from the sitemap otherwise. It costs one or two extra requests. Sent as a string for Clay compatibility."New value: +"When true (default) the catalogue size is estimated, from the Shopify products endpoint where the store is Shopify and from the sitemap otherwise. It costs one or two extra requests."Input schema / properties / skipCache / descriptionPrevious value: -"When \"false\" (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set \"true\" to force a fresh fetch. Sent as a string for Clay compatibility."New value: +"When false (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set true to force a fresh fetch."v1.0.0profile_ecommerce_platformScored across 1 tool
The server exposes a single, highly specific tool, so there is no possibility of selecting the wrong tool or overlapping with a sibling. Its purpose (platform/payment/app detection on a storefront) is stated precisely, including inputs, outputs and failure semantics.
The lone name profile_ecommerce_platform follows a clean verb_noun snake_case convention that is self-consistent and predictable. There is no mixed convention or vague verb to trip up an agent.
A one-tool server is thin by the usual standard, even though the tool is substantive and deep rather than trivial. It is arguably well-scoped to the narrow 'profiler' purpose, but a single call leaves no room for granular operations.
For the stated domain the tool covers the full profiling lifecycle in one call (platform, payment providers, apps, catalogue size, currencies, shipping, confidence, explicit not_extractable state). Minor gaps exist, e.g. no batch/listing operation for multiple domains or re-checking historical results, but nothing that creates a dead end.
MCP server for ua_e_commerce_price_tracker_mcp
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
Remote MCP server for hotel rate monitoring, parity checks, and pricing intelligence via Apify.
Apify MCP — run web-scraping Actors and fetch their dataset results.