Skip to main content
Glama
mambalabsdev

mcp-ecommerce-platform-profiler

Ecommerce Platform Profiler MCP Server

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

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.

What's Inside

Related MCP server: mcp-company-contact-details-extractor

What it does

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.

Quick start

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.

Prerequisites

  • Node.js 18 or newer

  • An Apify account with an API token

Example prompts

  • "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."

Inputs

  • 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.

Output

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.

Example output

{
  "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"
}

Features

  • 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

Full actor documentation

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


Mamba Labs GTM Suite

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

License

MIT

Built by Mamba Labs. https://apify.com/mambalabs

Available Tools

1 tool
profile_ecommerce_platformProfile Ecommerce PlatformA
Read-onlyIdempotent

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. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.

ParametersJSON Schema
NameRequiredDescriptionDefault
skipCacheNoWhen "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.
company_nameNoOptional 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.
checkCheckoutNoWhen "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.
company_domainNoBare 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.
escalateOnBlockNoWhen "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.
includeProductCountNoWhen "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.
includePaymentProvidersNoWhen "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.

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description layers substantial behavioral context beyond the readOnly/openWorld/idempotent annotations: no browser execution, static-read-only methodology, confidence tied to evidence kind (vendor header high, HTML substring low), the not_extractable fallback instead of guessing, and the requirement for an APIFY_TOKEN with per-call credit consumption. It is fully consistent with annotations — 'Read only' matches readOnlyHint=true, and the safety guarantees ('never adds an item, never starts a checkout, never submits anything') reinforce the non-destructive profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences, each earning its place: scope, output format, method/limitation, confidence model, and auth/cost. Core purpose is front-loaded in the first clause, and there is zero filler or restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema and no siblings, the description covers everything an agent needs to select and invoke it correctly: the detected attributes stand in for output fields, the flat-row return shape is stated, failure behavior (not_extractable) is disclosed, and operational requirements (credits, token, cost) are explicit. The rich input schema carries parameter semantics, leaving no material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema does the heavy lifting. The parameter descriptions are exceptionally rich on their own (caching semantics, why checkCheckout exists, residential-exit retry behavior), and the main description wisely does not repeat them. It adds only peripheral context like the APIFY_TOKEN credential requirement; no compensation for missing parameter documentation is needed.

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?

The description opens with a specific verb and resource — 'Detect which ecommerce platform a storefront runs on' — and enumerates the full target set (Shopify, WooCommerce, Magento, etc.) plus the secondary data points (payment providers, catalogue size, currencies, shipping destinations). It also states the output shape ('one flat Clay ready row'), leaving no ambiguity about what the tool produces.

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?

With no sibling tools to differentiate against, the description instead sets clear applicability boundaries: it is a static homepage/sitemap read, and a storefront that only reveals its platform after JavaScript runs is reported as not_extractable rather than guessed. This implicitly tells an agent when the tool is the right choice and when results will be inconclusive, though it stops short of explicit when-to-use/when-not-to-use phrasing or named alternatives.

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 observedprofile_ecommerce_platform

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool in the server, there is no possibility of confusing it with another tool. profile_ecommerce_platform has a singular, clearly described responsibility.

Naming Consistency4/5

The single tool name follows a clear verb_noun pattern (profile_ecommerce_platform), which is consistent with common MCP naming conventions. There are no other tools to contradict this convention, so consistency cannot be fully exercised.

Tool Count3/5

The server is intentionally narrow, but one tool is on the thin side and feels minimal for a domain that covers many detection dimensions. It is usable, but leaves no room for complementary operations such as batch profiling or evidence inspection.

Completeness4/5

The tool covers the core profiling domain well: platform detection, payment providers, apps, catalogue size, currencies, and shipping destinations. It gracefully handles non-extractable storefronts, though a truly complete surface might also expose raw evidence or allow batch/multiple URL processing.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    MCP server for the Mamba Labs People Finder & Email Verifier actor on Apify. Give it a company domain, name or LinkedIn URL and it returns the people at that company who match your role, seniority and department filters, each as a structured contact record with an optional verified business email.
    1
    37 npm
    MIT