mcp-ecommerce-platform-profiler

Profile Ecommerce Platform

profile_ecommerce_platform

Read-onlyIdempotent

Detect which ecommerce platform a storefront runs on and return payment providers, catalogue size, and shipping data to qualify or segment accounts before outreach.

Instructions

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.

Input Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.1.1Oct 16, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / checkCheckout / description

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

changedInput schema / properties / escalateOnBlock / description

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

changedInput schema / properties / includePaymentProviders / description

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

changedInput schema / properties / includeProductCount / description

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

changedInput schema / properties / skipCache / description

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

First observedv1.0.0Sep 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools

profile_ecommerce_platformA