Paper Desktop Release: How to Replace Figma with Cursor & Claude Code

Static design files are great for screenshots and approvals, but they fall apart the moment your UI needs to stay in sync with real code, real data, and fast-moving product decisions. As of February 2026, a new class of “AI-native” design workflows is emerging where the canvas is no longer a dead-end export. Paper Desktop’s MCP server is a strong example of this shift: it lets AI agents like Cursor and Claude Code read and write HTML (and related layout/style information) directly into your design canvas, while also pulling live content from sources like Notion.

This guide explains how Paper Desktop Release plus the Paper Desktop MCP server can help you replace Figma with AI design tools for many day-to-day product UI tasks. You’ll learn how the integration works, how to push/pull between code and canvas, how to sync real Notion data into designs, and how to build a repeatable “design-to-code” loop that feels more like software development than traditional handoff.

What Paper Desktop’s MCP server changes (and why it’s different from Figma handoff)

Paper’s approach is simple but consequential: treat the design file as something an agent can program. The Paper MCP server runs locally when you open a Paper file in the desktop app, exposing an authenticated interface that tools like Cursor and Claude Code can connect to. Once connected, an agent can read your canvas structure (nodes, styles, selection, screenshots) and also write HTML to add or replace content on the canvas. Paper’s docs explicitly frame this as using your design files as model context, with read/write access enabling workflows like syncing design system tokens and using real content in designs.

Under the hood, this is powered by MCP (Model Context Protocol). MCP standardizes how an AI host (like an IDE or CLI agent) connects to servers that offer resources (data), prompts (templated workflows), and tools (actions). The current MCP specification is versioned, and the latest published spec is 2025-11-25, built around JSON-RPC 2.0 messages and strong emphasis on consent, safety, and tool authorization.

The practical difference vs. most “design-to-code” handoffs is directionality:

• Traditional handoff: designer exports specs; developer re-implements; drift accumulates.
• AI-native loop: agent reads the canvas and edits it, then uses the same context to update code, validate spacing/responsiveness, and keep real content synchronized.

Current tool landscape (versions, dates, and why they matter)

Because this workflow depends on fast-changing agent tooling, it’s worth anchoring on what’s current right now:

Version awareness matters because MCP capabilities, authentication patterns, and tool schemas evolve. If an agent “knows” about MCP in general but your server schemas changed, you’ll see tool-call errors or mismatched parameters. Paper’s own troubleshooting notes that long-running agent sessions and schema/tool hallucinations can cause issues, and restarting the host or session is often the fastest fix.

Set up Paper Desktop MCP with Cursor and Claude Code

Paper Desktop’s MCP server is designed to be frictionless: install the desktop app, open a file, and the MCP server starts in the background. From there you connect your agent host.

Connect Paper MCP to Cursor

Paper provides a one-click install flow that adds Paper as an MCP server inside Cursor. Once installed, you’ll find it under Cursor Settings > Tools & MCP. If the server appears connected but the agent can’t use it in a session, reload Cursor or toggle the MCP server off/on.

Connect Paper MCP to Claude Code

In Claude Code, Paper’s docs provide a direct CLI command to register the MCP server (HTTP transport):

claude mcp add paper --transport http http://127.0.0.1:29979/mcp --scope user

After adding it, run /mcp in Claude Code to confirm the server appears and is available in the current session.

Verify the connection with a “small write”

Paper recommends a simple test prompt like “create a red rectangle in Paper.” The agent should request permission to use Paper tools, then you’ll see the result appear on the canvas. This is a good first check that the agent can both call tools and that the canvas is responding.

How “push/pull” replaces static Figma files in practice

The fastest way to think about replacing Figma with Cursor and Claude Code integration is to treat the Paper canvas as a living UI surface that stays close to your codebase. Instead of exporting specs, you create a tight loop:

1. Pull context from Paper into the agent (selection, tree summary, styles, screenshots, JSX export).
2. Generate or refactor code in your repo (React, Tailwind, CSS modules, whatever your stack is).
3. Push changes back into Paper by writing HTML to the canvas (or by updating content/styles in-place).
4. Repeat until the canvas and code converge.

Paper exposes tools that make this loop concrete. For example, it can export JSX (get_jsx) in formats like Tailwind or inline styles, fetch computed CSS (get_computed_styles), and then write HTML back into the design (write_html) either by inserting children or replacing an existing region. This is fundamentally different from “inspect and copy” because the agent can apply changes to the design, not just describe them.

A practical “pull” prompt pattern

When you want accurate code generation, your best leverage is to constrain scope. In Paper, select a single frame/component, then prompt the agent to:

• Read the current selection structure
• Extract computed styles
• Generate a component in your repo that matches the layout
• Return with a short checklist of what could drift (fonts, spacing, images, responsive behavior)

This “selection-first” workflow reduces token usage and reduces the chance the agent invents structure that isn’t in your canvas.

A practical “push” prompt pattern

Once the code is the source of truth, you can have the agent push a rendered or simplified HTML representation back into Paper for review. The key is to be explicit about intent: do you want it to replace an artboard region, or insert a new variant next to the original for comparison?

“When you can push code back into the canvas, the review artifact becomes editable, inspectable HTML instead of a screenshot.”

Design-to-code workflow principle

Sync real data from Notion into Paper (no more lorem ipsum)

One of the most immediately useful workflows in the Paper Desktop MCP server docs is pulling real content from Notion into a design. Paper specifically calls out using a Notion MCP server alongside Paper MCP so an agent can fetch database content (testimonials, pricing rows, FAQs) and then update the selected Paper frame.

This matters more in 2026 than it did a few years ago because Notion’s API has evolved significantly. Notion’s public API version 2025-09-03 introduced a database/data-source split for multi-source databases, and Notion’s developer changelog includes MCP-focused updates in January 2026 (including tool changes and bug fixes for Notion MCP). If your integration or MCP server targets the wrong API version, you’ll see confusing failures when querying “databases” that now behave like containers rather than tables.

Example workflow: Notion testimonials → Paper component

1. Open your design file in Paper Desktop (so the MCP server is running).
2. In Paper, select the component/frame you want to populate (for example, a testimonial card list).
3. In Cursor or Claude Code, ensure both Paper MCP and Notion MCP are connected in the same host.
4. Prompt the agent to fetch testimonials from the Notion database and replace placeholder content in the selected Paper frame.
5. Optional: ask the agent to translate content into a target language to stress-test layout expansion.

Once you’ve done this once, you can treat it like a repeatable content sync step during UI reviews. That’s one of the clearest ways to “replace Figma with AI design tools”: your review artifact always uses real data, and the agent can re-run updates as content changes.

Automate the design-to-code pipeline with an agentic checklist

The most sustainable way to use Cursor and Claude Code integration with Paper is to standardize a checklist your agent can follow every time. Paper’s own docs emphasize that results improve when the canvas is structured like code, using containers and flex layouts so the agent can infer layout intent reliably.

Recommended “agent brief” you can reuse

Drop this into your project’s internal docs (or a prompt template) and refine it per team:

// Agent brief: Paper ↔ repo sync
// Goal: keep Paper canvas and production code aligned with minimal drift.

1) In Paper: use the currently selected frame as the only source of truth for layout intent.
2) Read from Paper: structure, computed styles, and (if needed) a screenshot for visual confirmation.
3) Implement in repo: generate/modify components, styles, and assets.
4) Validate locally: run the dev server; ensure responsive behavior matches the design intent.
5) Push back to Paper: write HTML for the component (or a simplified preview) into a new artboard named "CODE SYNC".
6) Summarize differences: list any intentional deviations and any risky unknowns (fonts, rendering, spacing).

Where this beats a static Figma workflow

• Fewer translation steps: the agent speaks DOM/CSS fluently and Paper is web-native, so you’re not converting abstract design primitives back into HTML after the fact.
• Better iteration speed: you can update code and immediately regenerate a canvas preview for review, instead of waiting for a designer to re-export.
• Real data by default: content isn’t a last-minute scramble because the same agent can pull from Notion (or other MCP servers) and keep UI truthful.
• Auditable changes: your codebase has git history, tests, and CI. Use Paper as a collaborative surface, but keep “truth” in code.

Risks and guardrails you should adopt

MCP makes it easy for tools to do powerful things, so you should be deliberate about permissions. The MCP specification explicitly emphasizes user consent, data privacy, and the safety implications of tool execution. In practice, set guardrails like:

• Use “always allow” only for read-only tools; be selective for write tools like HTML writes or delete operations.
• Keep agent work in isolated folders or branches, then merge via normal code review.
• Restart agent sessions when tool calling becomes inconsistent (Paper notes long-running sessions often trigger issues).
• Prefer smaller, composable frames/components over huge pages when generating code.

Conclusion

Paper Desktop’s MCP server is a practical step toward an AI-native design workflow: the canvas becomes something your IDE agent can read, modify, and keep in sync with the codebase. With the Paper Desktop MCP server, you can connect Cursor and Claude Code integration to a web-based design surface, push/pull changes between code and canvas, and even sync real content from Notion so reviews happen on truthful UI instead of placeholder text.

If you want to start replacing Figma with AI design tools without blowing up your process, begin with one component: connect Paper MCP, standardize a “selection-first” agent prompt, generate a production component in your repo, and push a code-backed preview back into Paper for review. Once that loop feels reliable, expand to tokens, content syncing, and multi-breakpoint layouts. The long-term win is not “AI writes code,” it’s that your design artifacts become dynamic, testable, and continuously aligned with reality.