Why I built a Shopify behavioral-data MCP server (and what Clarity's couldn't do)

vjtuomin — Fri, 24 Jul 2026 11:47:57 +0000

Six months ago I started using Claude to help Shopify merchants with conversion work. The workflow was promising: connect the store's data, ask questions in plain English, get grounded answers instead of staring at dashboards. Then I hit a wall that took a while to articulate.

The wall was this: the behavioral data existed, but nothing exposed it in a shape an AI could actually reason over.

That's not obvious until you try to build on it. Let me break it down.

The layers of Shopify data, and which ones AI can reach
A Shopify store generates data in roughly four layers:

Business aggregates — GA4, Shopify Analytics. Revenue, sessions, conversion rate. Reachable via API, but summary data. It tells you conversion dropped, not why.
Order and customer records — the Shopify Admin API. Clean, structured, AI-reachable. Great for "who bought what," useless for "why did people not buy."
Behavioral events — clicks, scrolls, rage-clicks, funnel steps. This is where the "why" lives. Captured by Hotjar, Clarity, and similar.
Session recordings — video replays. Human-watchable, not machine-readable at all.
Layer 3 answers the questions merchants actually care about, and it's the one AI tools can't reach. Here's why.

Why the existing behavioral tools don't work for AI
Hotjar doesn't expose behavioral data through any API meant for programmatic reasoning. You watch recordings and look at heatmaps in their dashboard. The data is locked to human eyes.

Microsoft Clarity actually shipped an MCP server in 2025, which was the closest thing to what I wanted. But the limits made it impractical for real work:

10 API requests per day, per project. An AI assistant answering one question typically makes 3-5 tool calls (it decomposes, queries, validates). So 10 requests is ~2-3 real questions before a 24-hour lockout.
3-day data lookback. No week-over-week, no "did anything change after the redesign" if the redesign was four days ago.
3 dimensions per request, 4 total (browser, OS, country, device). No product, no cart, no funnel step, no session outcome.
So the most Claude could do with Clarity was "what was mobile engagement on Chrome in the last 3 days." A demographic question. Not "which product pages lose the most customers before add-to-cart," which is the question that moves revenue.

The deeper issue isn't the rate limit. It's that these tools structure data for dashboard rendering — coordinates for a heatmap overlay, timestamps for a replay scrubber. An LLM handed that data spends its context window parsing coordinates instead of reasoning about behavior.

What I built
Same capture, different priorities. A lightweight script (~15KB) collects the same behavioral signals Clarity and Hotjar capture — clicks, scroll depth, rage-clicks, funnel progression. The difference is what happens next.

Every event is tagged with Shopify context at ingest:

{
"event": "rage_click",
"element": "size-chart-toggle",
"page_type": "product",
"product_id": "8123...",
"product_title": "Merino Base Layer",
"cart_value_at_event": 0,
"session_outcome": "abandoned",
"device": "mobile"
}
That product_id / page_type / session_outcome tagging is the whole point. It means the AI can answer "which products have the highest rage-click rate on mobile before abandonment" — a four-dimension question that Clarity's three-dimension cap structurally can't express.

The data is aggregated for LLM context, not dumped raw. Early on I made the mistake of exposing raw event streams. A busy product page generates thousands of events a day; handing an LLM 5,000 rows burns the context window and produces worse answers than a well-shaped summary. So the MCP tools return pre-aggregated views — "rage-click rate by product, by device, by session outcome" — with the option to drill down. Shape the data for the reasoning pattern, not for completeness.

Exposed over MCP with token-scoped auth. Each merchant gets a revocable token scoped to their store. The tools are read-only resources (query behavior), not write actions. Any MCP client works — Claude Desktop, ChatGPT where MCP is supported, Cursor.

The honest limitations
It's closed-source. The capture script and the aggregation layer are the product. I went back and forth and landed on closed for now.
Shopify-only. The whole value is in the Shopify-specific tagging. A generic version would lose exactly the thing that makes it useful.
"Session replay" is event-level, not video. You can reconstruct what happened from the structured events, but there's no video scrubber. That's deliberate — video is for humans, structured events are for AI.
It's early. A few design-partner stores, a public launch on the Shopify App Store, and a lot still to build.
Why MCP specifically
I could have built a normal REST API. MCP mattered because the whole point is that the merchant's own AI tools consume the data. With MCP, a Shopify operator connects the server to whatever they already use — Claude, ChatGPT, Cursor — in about 30 seconds, and the AI picks the right tool based on the question. A REST API would have meant every integration is a custom job. MCP made it one protocol, any client.

If you're newer to the protocol, I wrote up what an MCP server is separately.

Try it, or tear it apart
It's on the Shopify App Store as ClickContext, free during early access.

I'd genuinely like to hear where this breaks — especially the aggregate-vs-raw design and the closed-source call. Both are decisions I could see going the other way.

DEV Community: vjtuomin

Why I built a Shopify behavioral-data MCP server (and what Clarity's couldn't do)