Why I Use Cursor With the Figma MCP — and Why I Still Test on a Cabled iPhone

"AI-assisted frontend" used to mean pasting a screenshot into a chat and getting back CSS that was close, but never quite the right gap, the right gray, the right line-height. Model Context Protocol changed that for design handoff specifically. Cursor talks to Figma's MCP server, and instead of flattening a frame into pixels for the model to guess at, it gets the actual node tree: auto-layout, spacing values, bound variables, component names, type scale. That is the part I actually rely on daily.

1. What the MCP actually gets right

I select a frame in Figma, hand Cursor the link, and it queries the MCP server for that node. What comes back is structured: an 8px gap is the literal number 8, not something I measure with a ruler tool on a PNG. A color is the design token or hex the designer bound, not a value I pick with an eyedropper and hope matches. Font weight, line-height, corner radius, the actual component hierarchy — all of it arrives as data, not as a picture I reverse-engineer.

• Spacing that matches the design system, not the nearest round number I guessed.
• Colors and type as tokens, so a rebrand updates one variable instead of a grep across components.
• Component boundaries that match how the designer actually grouped things, which makes the generated markup easier to keep semantic.

2. What I still check by hand

Structured data is not judgment. A Figma frame shows one breakpoint at a time; it does not tell Cursor what happens between 768px and 1024px, or what a card looks like with a two-line title instead of one. It has no empty state, no error state, no loading skeleton, because those never had a design frame to begin with. And generated markup can be structurally accurate to the frame while still being a div where a button, a nav, or a heading tag belongs — I still read every component for semantics and keyboard access before it merges.

3. Why an emulator is not enough

Chrome DevTools' device toolbar is Chromium rendering a resized viewport. It is not WebKit, it does not have iOS Safari's dynamic viewport behavior, and it will not show you the bugs that only exist on the real engine. So the last step before anything ships is plugging an actual iPhone into my Mac with a cable. Settings → Safari → Advanced → Web Inspector, turned on once on the phone. Then a Lightning or USB-C cable to the Mac, Safari's Develop menu picks up the device, and I get a live Web Inspector — real DOM, real console, real network panel — attached to a page that is actually running on iOS Safari, not a simulation of it.

That is where I catch the bugs an emulator hides: safe-area-inset padding that looks fine in DevTools and clips under the notch on the real phone, 100vh jumping when Safari's address bar collapses on scroll (dvh fixes it, but only testing it live proves that), the input-focus jump when the keyboard opens with a fixed footer on screen, rubber-band overscroll dragging the whole layout, and how the page actually behaves added to the home screen as a standalone PWA. None of that shows up in an emulator. All of it shows up the first time a real customer opens the link on their own phone — so I would rather see it first.

4. Why Safari specifically — the browser I am actually shipping for

I look at analytics before I decide what "correct" even means for a project. For most of the small-business and service sites I build, the customer opening the site is on a phone, arriving from Instagram, Telegram, Google Maps, or a text message — and for a large share of that traffic, that phone is an iPhone. Desktop Chrome is where I develop. iOS Safari is where the person with the credit card actually is. Optimizing pixel-perfection for the browser I am staring at all day and skipping the one my client's customer is actually holding is optimizing for the wrong audience.

The actual loop

Figma frame, selected and handed to Cursor through the MCP. Component built from real tokens, not guessed pixels. A pass for semantics, states, and breakpoints the frame never showed. Then the iPhone comes out of the drawer, plugs into the Mac, and the same page runs live in Safari's Web Inspector on the real engine. Only after that does anything merge. Two different tools, two different jobs: one gets me close to the design fast, the other tells me the truth about the device the client's customer is actually going to use.

Want it to actually look right on the phone your customer holds?

This is the pipeline I run on every build: real design tokens in, real device out. Reach out via the contact form and tell me which platform your customers actually use — I will build and test for that one, not for the browser that is convenient for me.