Blog · · 5 min
MCP server for conversion rate optimization
No MCP tells you where to put a button. What exists splits into three families — measurement (Microsoft Clarity, PostHog, Chrome DevTools), experimentation (GrowthBook) and heuristic audit — and we checked the official registry today: searching conversion returns eight servers, all of them document format converters. Here is which family to connect, and the sample size below which a test proves nothing.
There is no MCP that makes a page convert. There are MCPs that measure a page, MCPs that run an experiment on it, and MCPs that score it against a checklist — three different jobs, and only the first two produce evidence. We searched the official Model Context Protocol registry on 24 August 2026: conversion returns eight servers, seven of them GroupDocs document format converters and one a PDF-to-JSON tool. upsell, landing page, a/b testing, ui components and component library each return zero. Whatever you connect, you are connecting it from outside that registry.
Family one — measurement
These read what already happened. They are the only tools in the category that cannot lie to you, because they report rather than judge.
Microsoft Clarity MCP. npx @microsoft/clarity-mcp-server --clarity_api_token=your-token-here. Official Microsoft package, three tools: query the analytics dashboard, list session recordings with filters, query the documentation. Clarity itself is free, which is why it is the default recommendation.
Its limits are the part nobody quotes, and they decide whether it is usable in a loop. Microsoft's Data Export API documentation states a maximum of 10 API requests per project per day, retrieval confined to the previous 1 to 3 days, a maximum of three dimensions per request, and responses capped at 1,000 rows with no pagination. An agent that polls Clarity on every iteration will exhaust the day's quota before lunch. Treat it as a once-a-day pull into your own store, not as a live sensor.
PostHog MCP. npx @posthog/wizard mcp add. Runs HogQL queries, ships feature flags, reads error traces. If the merchant already has PostHog, this is the shortest path from a question to a number.
Chrome DevTools MCP. npx chrome-devtools-mcp@latest. Published by Google, Apache-2.0. It drives a real Chrome through puppeteer-core, so an agent can load the actual page and read the actual trace instead of reasoning about the source. This is the one that turns "the page feels slow" into a measurement.
Family two — experimentation
GrowthBook MCP. The @growthbook/mcp package describes itself as a thin MCP for GrowthBook: a skill loader plus an authenticated API passthrough. GrowthBook is open source and self-hostable, which matters when the merchant's traffic is small enough that per-seat experimentation pricing makes no sense.
Intelligems is the Shopify-native price and offer testing tool that comes up constantly in this category. As of 24 August 2026 we found no package published on npm under that name; if they run a hosted MCP endpoint, connect it as a remote server rather than looking for a CLI.
Family three — heuristic audit, and its ceiling
This is where the search results are thickest and the evidence is thinnest. A heuristic audit loads your page, compares it to a list of rules, and returns a score.
Baymard UX-Ray is the serious member of the family — it scans an ecommerce site against Baymard's own UX guideline database and groups findings by severity. Reading its public page on 24 August 2026, it publishes a methodology link but no accuracy figure on that page, and mentions neither an API nor an MCP. There is a free demo scan.
The rest of the category — the landing-page graders, the AI CRO scorers — share one structural problem, and an agent should say it out loud to the merchant rather than pass the number along. A generated score is an exam the tool sets and marks itself. It correlates with the tool's rulebook, not with the merchant's revenue, and none of the ones we could read publish a correlation between their score and a measured conversion change. A score is useful as a checklist. It is not evidence.
The number that decides whether any of this matters
Before an agent recommends an A/B test, it should compute whether the merchant can run one at all. This is arithmetic, not opinion.
For a two-proportion test at 95% confidence and 80% power, the sample per variant is roughly n = 2 × (1.96 + 0.8416)² × p̄(1−p̄) / δ².
Run it on a realistic store. Base conversion 2%, and you want to detect a 20% relative lift (2.0% to 2.4%): about 21,000 sessions per variant, so 42,000 sessions for the test. Want to detect a 10% relative lift (2.0% to 2.2%): about 81,000 sessions per variant, 162,000 in total.
A shop doing 10,000 sessions a month cannot detect a 10% lift inside a quarter. That is not a reason to do nothing — it is a reason to change what you do. Below that threshold, ship changes that are defensible on grounds other than a test: a legal requirement, a documented usability finding, a page that loads. And stop scoring.
What to actually connect
- The merchant already has PostHog:
npx @posthog/wizard mcp add, and query real funnels. - No analytics at all: install Clarity, then the Clarity MCP, and respect the ten-calls-a-day ceiling.
- Something is slow or broken and nobody knows where:
npx chrome-devtools-mcp@latest. - Traffic above roughly 40,000 sessions a month and a real question to settle: GrowthBook, self-hosted.
- Traffic below that: no experimentation stack. Fix the mechanics that do not need a test — see where to place an upsell and the bundle selector spec.
The gap, stated plainly
To our knowledge, as of 24 August 2026, no MCP hands an agent a placement rule. Every server in this category returns data about a page that already exists; none tells the agent what to build. That is a real hole, and an agent asked to improve a store today has to fill it from its own priors — which is exactly why the pages it produces resemble each other.
Disclosure — we are building uxgen, an MCP aimed at that hole. It is not installable yet, and nothing above is ours.