Page friction, in your editor
Find the pages quietly frustrating real users.
Rage clicks, dead clicks, quickback and scroll death. Per page, tracked over time, with a verdict on what to fix, right where you write the code.
Reads your own Microsoft Clarity data, over an API token you control and can revoke.
Example output. Illustrative figures, showing the shape of a response.
One line. That's the whole setup.
Paste it into your editor, sign in, then add your Clarity API token.
claude mcp add --transport http frictionscope https://frictionscope.dev/mcp/frictionscopeWorks in Claude Code, Cursor, Cline, Windsurf, or any editor that speaks MCP.
The difference
Clarity has the data. Getting it out, per page, over time, is the hard part.
Clarity keeps your recordings for 30 days and your heatmaps for nine months, and its dashboard is genuinely good. But the Data Export API, which is the only programmatic way in, is confined to the previous one to three days, allows ten requests per project per day, and returns at most 1,000 rows with no pagination.
So the numbers exist, but any answer that needs them lined up per page across weeks does not: no trend, no ranking that survives a refresh, and no honest answer to "did the change I shipped last Tuesday actually help?" That takes a store of your own, filled one day at a time.
The export API, and the official MCP
- × Fetches live, keeps nothing
- × Previous 1 to 3 days only
- × 10 calls a day, 1,000 rows, no pagination
- × Raw metrics, no verdict, no before and after
FrictionScope
- ✓ Snapshots every night, and stores it
- ✓ History that outlives the API window
- ✓ One archetype verdict per page
- ✓ Compare a page before and after a date
A missed night cannot be recovered, which is exactly why the snapshot runs on a schedule rather than on demand.
The verdict
Every page gets one answer, not twelve numbers.
Raw counts say nothing on their own: three rage clicks across five sessions is a disaster, three across five thousand is noise. Every signal is judged as a per-session rate, and then the page is classified.
The raw rate is shown next to every verdict, so a badly calibrated threshold is obvious instead of hidden.
In the editor
Four read-only tools, where you already work.
The web app and the editor read the same store, so the browser and your agent cannot disagree. Nothing ever writes back to Clarity.
pages_overview
Every page ranked by how much attention it needs, each tagged with its archetype.
whats_broken
Only the error-click and script-error pages. The "is anything on fire" glance.
page_detail
One URL: every signal, its verdict, and the trend across stored history.
page_compare
One URL before and after a date. This is how you prove a fix worked.
Where this is right now
FrictionScope is early, and not yet open to the public. The daily snapshot, the classifier and the four MCP tools are built and running against a real site: ours. The thresholds are still being calibrated against real data, which is exactly why every verdict shows its raw rate beside it.
There is no pricing page yet, because there is nothing to sell yet. When that changes, it will say so plainly.
Stop guessing which page is the problem.
Connect a site, add your Clarity token, and the first snapshot lands tonight. History starts accumulating from that moment, because it cannot be backfilled later.