Which integrations are available for this server?

Provides checks for Google Merchant Center compliance on public product pages, including price and availability markup, duplicate or conflicting Product blocks, and product identifiers, as well as AI shopping readiness for Google AI Mode signals. Uses the Google PageSpeed Insights API to retrieve Core Web Vitals during store audits when available, with support for GOOGLE_PAGESPEED_API_KEY for a higher quota. Checks Shopify storefronts for legacy checkout scripts and exposure to Shopify's 2026 checkout extensibility deadlines, and audits Shopify pages for SEO, structured data, images, links, trust signals, and speed.

storefront-checks

by VladSF415

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

storefront-checks

Free, rules-based checks for e-commerce product pages, as a Node library, a CLI and an MCP server.

AI shopping readiness: does a product page give ChatGPT, Google AI Mode, Perplexity and Copilot what they use to recommend it? Product structured data, price and stock, GTINs (with check digits), reviews in the markup, return and shipping terms, answers to buyer questions, and whether AI crawlers are allowed in.
Google Merchant Center compliance: price and availability in the markup against the visible page, duplicate or conflicting Product blocks, and product identifiers.
Store audit: SEO basics, structured data, images, broken links, trust signals and speed.
Shopify checkout deadlines: signs of legacy checkout scripts and tracking ahead of Shopify's 2026 checkout extensibility deadlines, plus a checklist for what only the admin shows.

No AI model is called and nothing is stored. Each check fetches public pages and applies rules. These are the same engines behind the free web tools on Extensions Market.

Quick start

npx -y github:VladSF415/storefront-checks ai https://store.example/products/blue-mug

Commands: ai, gmc, checkout, audit. Add --json for JSON output, or --json --full for the engine's whole report.

Example output from a real product page:

Score: 76

Areas:
   94  Product identity & data
   20  Reviews & authority
   67  Merchant trust signals
   70  Buyer-question coverage
   91  Price, stock & variants
   91  Commercial data hygiene
  100  AI crawler access & indexing
   75  Agent buying path

ChatGPT feed: 9 required fields found

Top issues:
  1. [high] AggregateRating schema (star ratings): not detected
     Fix: Use a reviews app (Judge.me, Loox, Yotpo) that renders visible stars and outputs AggregateRating schema.
  2. [medium] Return policy in the markup (hasMerchantReturnPolicy): not detected
     Fix: Add a MerchantReturnPolicy (applicableCountry, returnPolicyCategory, merchantReturnDays) to your Organization markup or to the Offer.

Related MCP server: CatalogReady

Use it from an AI assistant (MCP)

Four tools, each taking { "url": "..." }:

Tool	What it checks
`check_ai_shopping_readiness`	One product page against the signals AI shopping tools use
`check_merchant_center`	One product page for Merchant Center price, stock and markup problems
`check_shopify_checkout`	A Shopify store's exposure to the 2026 checkout deadlines
`audit_store`	SEO, structured data, images, links, trust signals and speed of one page

Claude Code:

claude mcp add storefront-checks -- npx -y -p github:VladSF415/storefront-checks storefront-checks-mcp

Claude Desktop, Cursor and other MCP clients:

{
  "mcpServers": {
    "storefront-checks": {
      "command": "npx",
      "args": ["-y", "-p", "github:VladSF415/storefront-checks", "storefront-checks-mcp"]
    }
  }
}

Docker: docker build -t storefront-checks . && docker run -i --rm storefront-checks starts the same stdio server.

Then ask something like "Check https://store.example/products/blue-mug for AI shopping readiness and tell me what to fix first."

Use it as a library

npm install github:VladSF415/storefront-checks

const { checkAiShopping, checkMerchantCenter, auditStore, checkShopifyCheckout, gtinValid } = require("storefront-checks");

const report = await checkAiShopping("https://store.example/products/blue-mug");
console.log(report.overall, report.issues.slice(0, 3));

gtinValid("6291041500213"); // true: the check digit matches

Every function takes a URL and returns the engine's full report. compareAiShopping(url, [competitorUrl1, competitorUrl2]) runs the AI shopping check on your page and up to two competitor pages.

Limits

It sees what a public page shows. Merchant Center account status, Shopify admin data and the feeds you send to shopping channels aren't visible to it.
It checks one page per call. The store audit also requests the page's links, so keep volume reasonable.
Core Web Vitals come from the Google PageSpeed Insights API when it answers. Set GOOGLE_PAGESPEED_API_KEY for a higher quota.
Localhost and private network addresses are refused.

Web versions

The same checks, free in the browser with no signup:

License

MIT. Made by Extensions Market, which also builds EZstock, a Shopify app for reorder planning, purchase orders and receiving.

Available Tools

4 tools

audit_storeA

Read-only

Audit one store page for SEO basics, structured data, images, broken links, trust signals and speed. Core Web Vitals come from the Google PageSpeed Insights API when it answers, which can take up to about 40 seconds.

Name	Required	Description	Default
`url`	Yes	A public page URL, e.g. https://store.com/products/blue-mug

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only and open-world behavior; the description adds genuinely new operational context: Core Web Vitals come from an external PageSpeed Insights API, it may be unavailable ('when it answers'), and the call can take ~40 seconds. That latency and partial-result warning is exactly the kind of detail an agent can't get from annotations.

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?

Two tight sentences, front-loaded with what is audited, followed by the latency/API caveat. Nothing redundant and every clause carries information.

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 one fully-documented parameter and no output schema, the description covers scope, cost, and data-source uncertainty. It stops short of describing what the result contains (scored findings, issue list), leaving the return shape to inference.

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 coverage is 100% and the single url parameter is fully documented with an example, so the schema carries the load. The description adds only 'one store page' scope, which is marginal beyond the schema's 'public page URL' description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb (audit) plus a scoped resource (one store page) and an enumerated list of what gets checked: SEO basics, structured data, images, broken links, trust signals, speed. It does not explicitly state how it differs from the sibling checks (check_ai_shopping_readiness, check_merchant_center, check_shopify_checkout), though the naming plus scope makes differentiation reasonably inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'one store page' and the per-dimension scope, but there is no explicit when-to-use/when-not-to-use guidance and no pointer to which sibling to pick for adjacent checks. The 40-second caveat helps an agent plan but isn't selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_ai_shopping_readinessA

Read-only

Grade one product page on the signals AI shopping tools (ChatGPT, Google AI Mode, Perplexity, Copilot) use: Product structured data, price and stock, GTINs, reviews in markup, return and shipping terms, buyer-question coverage and AI crawler access. Returns a 0-100 score per area and the top issues with fixes.

Name	Required	Description	Default
`url`	Yes	A public page URL, e.g. https://store.com/products/blue-mug

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with both (a read-only grading of a public URL). It adds genuinely useful context beyond annotations: the return shape is a 0-100 score per area plus top issues with fixes, which matters because there is no output schema. No mention of runtime, rate limits, or failure modes for unreachable pages.

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?

Two sentences, both front-loaded: the first states what is graded and against which consumers, the second states the return shape. The long signal list is dense but every item is a real grading criterion, not filler.

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?

For a one-parameter, no-output-schema tool, the description covers the input scope, the evaluation criteria, and the return format, which is enough to call it correctly. The only gap is that it never states prerequisites or behavior for pages that fail to load or block crawlers.

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?

With a single parameter and 100% schema description coverage (including a concrete URL example), the schema already carries the semantics. The description only reinforces the 'one product page' scope and does not add format or constraint details beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('grade') plus a precisely scoped resource ('one product page'), with the graded signals enumerated so the agent knows exactly what the tool evaluates. The 'one product page' scope implicitly separates it from the store-level audit_store sibling, but no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The framing ('signals AI shopping tools use') makes the use case inferable, but there is no explicit when-to-use statement, no when-not, and none of the siblings (audit_store, check_shopify_checkout, check_merchant_center) are referenced as alternatives. The agent must infer that this is the per-page option versus the store-level audit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_merchant_centerA

Read-only

Check one product page for Google Merchant Center problems: price and availability in the markup vs the visible page, duplicate or conflicting Product blocks, missing identifiers. Page-level only; it does not log in to Merchant Center.

Name	Required	Description	Default
`url`	Yes	A public page URL, e.g. https://store.com/products/blue-mug

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful context beyond them: it explicitly states no Merchant Center login is needed and that the check compares markup against the rendered page. It stops short of describing return shape or fetch/rate behavior.

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?

Two dense sentences: the check list comes first, the scope/auth caveat second. No filler, no restatement of the tool name.

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?

For a one-parameter read-only tool with no output schema, the description covers what is examined and what is out of scope. The remaining gap is that an agent cannot anticipate the result shape (pass/fail per check, findings list) since no output schema exists.

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?

There is a single parameter with 100% schema description coverage, which already establishes the baseline of 3. The description reinforces that the URL must point at one public product page, but adds no format or validation detail beyond the schema's example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Check one product page for Google Merchant Center problems') and enumerates the exact checks performed (price/availability mismatch, duplicate Product blocks, missing identifiers). It is clear about scope but never names the siblings (audit_store, check_ai_shopping_readiness) it should be preferred over.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Page-level only; it does not log in to Merchant Center' clause sets a boundary, implying this is a single-page public check rather than a store-wide or account-level audit. However, it never explicitly says when to choose this over audit_store or check_ai_shopping_readiness, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_shopify_checkoutA

Read-only

Check a Shopify store's exposure to the 2026 checkout extensibility deadlines from its public pages (legacy checkout scripts and tracking), plus a checklist for what only the admin shows.

Name	Required	Description	Default
`url`	Yes	A public page URL, e.g. https://store.com/products/blue-mug

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses a real behavioral limit: detection is limited to public pages (legacy checkout scripts and tracking), and admin-only factors are returned as a checklist rather than observed. That tells the agent the results are partial, which is valuable and non-obvious.

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?

A single front-loaded sentence with the deadline context first and the scope qualifier second. Dense but every clause (public pages, legacy scripts/tracking, admin checklist) carries information; only the parenthetical is slightly redundant.

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?

For a one-parameter read-only audit with no output schema, the description covers what is checked, on what surface, and what is deliberately not checked (admin-only items). It stops short of describing the shape of the returned findings, which is the remaining 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?

Only one parameter and schema coverage is 100%, so the schema already explains 'url' with an example. The description restates that it must be a public page URL but adds no format or constraint detail beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('check') plus a precise resource ('Shopify store's exposure to the 2026 checkout extensibility deadlines') and an explicit scope ('from its public pages'). It is clearly distinct from siblings like check_ai_shopping_readiness and check_merchant_center by topic, though it never names them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the framing (audit a store's legacy checkout scripts from public pages), but there is no explicit statement of when to pick this over audit_store or the other check_* siblings, and no stated prerequisites.

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.

4 tool updatesv0.1.0Oct 25, 2026
- First observedaudit_store
- First observedcheck_ai_shopping_readiness
- First observedcheck_merchant_center
- First observedcheck_shopify_checkout

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-10-25 01:20 across 4 tools

Disambiguation4/5

Each tool targets a distinct check area: AI shopping readiness, Merchant Center compliance, Shopify checkout extensibility, and broad storefront auditing. There is some overlap because three tools inspect page markup and structured data, but the descriptions draw clear boundaries between them.

Naming Consistency4/5

Three tools use the check_* prefix in snake_case, while audit_store uses a different verb. The deviation is minor and still readable, with all names following a predictable verb-resource style.

Tool Count5/5

Four tools is a well-scoped set for a focused storefront-checking server. Each tool covers a meaningful, non-trivial audit area without unnecessary bloat.

Completeness4/5

The surface covers key storefront concerns: AI readiness, Merchant Center, Shopify checkout, SEO, structured data, links, trust signals, and speed. Minor gaps remain, such as store-wide crawling, accessibility, or mobile-specific checks, but agents can work around them for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Surfaced: Shopify AI Shopping Readiness A
com.onrender.surfaced-srzj
Check any Shopify store's readiness for ChatGPT & AI shopping agents. Free, no API key, 8 languages.
E-commerce & Retail AI & Machine Learning Marketing
31
https://surfaced-srzj.onrender.com/mcp
agentbuilt A
dev.agentbuilt
Free AI-readiness audit of any URL: AI crawler rules, JS-free text, JSON-LD, llms.txt. Tool catalog.
Browser Automation Web Scraping
31
https://agentbuilt.dev/api/mcp
AI Catalog by Crescendo Lab A
com.cresclab.catalog
Check if a product feed is ready for AI shopping (ChatGPT, Gemini, AI Mode): score, gaps, fixes.
E-commerce & Retail AI & Machine Learning Marketing
31
https://catalog.cresclab.com/api/mcp/
Storefront Check A
com.profitpather.tools
Audit any storefront from outside: ad tags, dead-tag detection, AI crawler access, feed readiness.
E-commerce & Retail Marketing Web Scraping
41
https://tools.profitpather.com/store/mcp

Related MCP Servers

Lighthouse MCP
Web Scraping App Automation Monitoring
danielsogl
A
license
B
quality
B
maintenance
MCP server that enables AI agents to perform comprehensive web audits using Google Lighthouse with 13+ tools for performance, accessibility, SEO, and security analysis.
Updated a day ago (2026-10-23 20:11 UTC)
11
2,007 npm
73
MIT
CatalogReady
E-commerce & Retail Web Scraping
PO-VINCENT
A
license
B
quality
C
maintenance
MCP server for auditing product pages to determine AI shopping agent readiness, providing a 0–100 score and actionable fixes.
Updated 3 months ago (2026-07-23 12:16 UTC)
11
5
Apache 2.0
mcp-google-merchants
E-commerce & Retail Marketing
A1-x-Tech
A
license
A
quality
A
maintenance
Enables AI assistants to manage Google Merchant Center accounts via the Merchant API, including product feeds, promotions, data sources, and MCQL reports with read and write operations.
Updated 21 days ago (2026-10-04 11:30 UTC)
28
40 npm
MIT
CrawlBit MCP
Marketing Search
amati032-dev
A
license
A
quality
C
maintenance
Provides four free tools to assess AI visibility: crawler access, entity recognition, off-page gaps, and shopping agent compatibility, without requiring an API key.
Updated 2 months ago (2026-08-14 22:25 UTC)
4
18 npm
1
MIT