Two small MCPs that took the busywork out of my week

I built one MCP that checks a live page against its Figma frame, and one that lets Claude read Microsoft Clarity data. Both cut out repetitive work so I can spend the time on design.

  • 5 min read
  • MCP · Claude Desktop

Written by Madhav Nair

The problem

Two jobs kept eating my time.

  • Design QA. Checking a built page against its Figma frame means hunting for things that are almost right: a color one shade off, a font that didn't load, a radius that should be a pill. It's slow, and it's easy to miss things.
  • Insight digging. Microsoft Clarity has the behaviour data, but its public API only looks back 1 to 3 days and can't filter by page. Ask for a breakdown of a whole site and you can get thousands of rows, enough to hit size limits.

Both tasks are repetitive, and both are ones I'd rather do by asking.

The idea: let Claude do the legwork

MCP (Model Context Protocol) lets Claude call tools that run on my machine. So I built two small local servers and connected them to Claude Desktop:

  • Figma Live Design QA MCP compares a Figma frame with a live page and writes a shareable HTML report. Published 30 July 2026.
  • Clarity MCP Server gives Claude Clarity data with page-level filtering and a local history of daily snapshots. Published 20 July 2026.

Claude sits in the middle. I describe what I want in plain words, and it picks the tools.

Workflow 1: a design QA run

  1. In Figma, I select the frame and copy its link.
  2. I open the matching page in a local, preview or staging build.
  3. I paste both links into Claude and ask for a design QA check, adding viewport, theme, locale and anything that's meant to be different.
  4. Claude runs run_design_qa. It reads the frame, reads the live page, compares the values and builds the report.
  5. I open the HTML report and go through the findings.

An example request (example URLs, not a real project):

Example request
Run design QA on https://www.figma.com/design/FILE_KEY/Checkout?node-id=12-34
against https://staging.example.com/checkout. Light theme, en-US.

Design decisions

  • Tokens, not pixels. It checks colors, font loading, font sizes, font weights and border radii. It doesn't do a pixel diff on purpose: Figma often has placeholder content while the live page has real data, so a pixel diff mostly gives you noise.
  • Near misses get flagged. A color one channel away from a design color often means someone typed the value by hand. The report flags these as likely hardcoded drift.
  • One issue, not thirty alerts. Findings are grouped by value, so one hardcoded color used in 30 places shows up once, with a severity, the closest design value, a count and where to look.
  • Honest about what it can't check. If there isn't enough design evidence, the result is not_verified, not a fail.
  • Exceptions are remembered. dismiss_finding saves an intentional difference for that Figma file, so it doesn't come back on every run.
  • Retry a step, not the whole run. Each run has a runId, so if one step fails Claude can rerun just that step.
  • A report people can share. It's a single HTML file that opens on its own, with a render of the Figma frame next to crops from the build.

It doesn't check copy, layout geometry, line height or pseudo-elements.

Workflow 2: Clarity insights on request

Clarity's API has hard limits: 10 requests per project per day and a 1 to 3 day window. The server works within those limits:

  • get_clarity_insights fetches live data, optionally filtered to pages whose URL contains a string such as /checkout. If I ask for a page filter, it adds the URL breakdown automatically.
  • capture_clarity_snapshot saves today's data to a local file. Run it roughly daily and you build up a history Clarity doesn't keep for you.
  • get_clarity_historical_insights reads saved snapshots for a date range. It tells me which days it found and which are missing.

An example exchange (example page and dates):

Example exchange
Me: How did /checkout do from 14 to 20 July?
Claude: calls get_clarity_historical_insights
        { startDate: "2026-07-14", endDate: "2026-07-20", urlFilter: "/checkout" }

Design decisions

  • Filter after fetching. Filtering by URL once the data comes back avoids the oversized responses, and I can focus on one page without spending another request.
  • Per-day data, not made-up totals. Clarity mixes counts, percentages and rates, and there's no documented way to merge them across days. So the server returns each day as it is and lets Claude reason over it.
  • Missing days are stated, not hidden. A gap in the history shows up as a missing date.
  • Analytics stay off GitHub. Snapshots are kept out of the repo by .gitignore because they're user data.

The daily routine

I run a Clarity insights routine in Claude every day. The daily rhythm matches how the server is meant to be used: the repo suggests capturing a snapshot roughly once a day, and each day captured adds to the history I can query later.

What changed

Design QA. Checking a feature against its Figma frame used to take me half a day. Now it takes about 10 minutes per feature.

Clarity insights. I know what my users are doing, compared to what they tell me during user interviews.

Try them

Both are open source under the MIT license:

Send a connection request with a short note about what you're working on.

Connect on LinkedInGitHub

Or mmadhavnair@gmail.com