I’ve been actively building a project in Cursor, and at this point it has become the place where the application actually lives.
Cursor knows the codebase. It understands the components, the architecture, the existing functionality, and — perhaps most importantly — all the weird implementation details that accumulate once a side project becomes a real product.
But there was one part of the workflow where I still wanted something else. Design.
Lovable is extremely good at taking a rough product idea and quickly turning it into a polished visual direction. I like using it to explore layouts, interactions, styling, and general UI direction.
The problem was the handoff. I didn’t want to constantly jump between Cursor and Lovable, manually explain the same application context, copy code back and forth, or let two separate AI coding environments independently modify the same project.
Cursor owns the product. Lovable gets commissioned for design work. I decide what comes back.
With Lovable’s MCP server, that workflow now works surprisingly well.
The mental model
I think of the setup like a very small product team. Cursor is the lead engineer: it understands my actual repository and remains responsible for the production implementation. Lovable is the design specialist: I can hand it a screen or a design problem and let it explore a stronger visual direction. And I’m still the approval layer — Lovable can experiment freely, but nothing needs to land in my local codebase until I decide it should.
That distinction is important. This is not “let two AI coding tools edit the same app.” It is “let one AI agent intelligently delegate a specialized task to another tool.” That feels much closer to the way I actually want agentic development to work.
Why MCP changes the workflow
MCP — Model Context Protocol — gives AI tools a standardized way to expose capabilities to other agents. Instead of treating Lovable as another browser tab I have to manually operate, Cursor can treat Lovable as a tool.
Lovable exposes an MCP server that external clients such as Cursor can connect to. Once connected, Cursor can use Lovable capabilities such as:
- listing projects
- interacting with an existing project
- sending messages to the Lovable agent
- inspecting files
- reading diffs
- reviewing edit history
- retrieving project information
That is the key shift. I’m no longer moving between two isolated AI environments. I’m letting one of them call the other.
Connecting Cursor to Lovable
I wanted the Lovable connection to belong specifically to this project, so I added a project-level MCP configuration. In the root of the Cursor project, I created .cursor/mcp.json:
1{2 "mcpServers": {3 "lovable": {4 "type": "http",5 "url": "https://mcp.lovable.dev",6 "auth": {7 "CLIENT_ID": "6d465f583e1e4ce5801b1616f735670c"8 }9 }10 }11}Lovable currently documents this exact configuration for Cursor. Cursor also supports a global MCP configuration in ~/.cursor/mcp.json, but for this workflow I prefer keeping it project-specific.
After saving the file, I reloaded Cursor with Cmd + Shift + P, then Developer: Reload Window.
Targeting one existing Lovable project
This was another important detail for me. I did not want Cursor creating a new Lovable project every time I asked for design help. I already had a Lovable project I wanted to use as the design counterpart to my local application.
So I asked Cursor: “List my Lovable projects and give me the project ID for [PROJECT NAME]. Do not modify anything.” Once Cursor returned the ID, I used that ID in a project rule.
This means I now effectively have one Cursor repository bound to one specific Lovable project — instead of a random new Lovable project every time. That makes the whole workflow much more predictable.
Teaching Cursor how to use Lovable
Connecting the MCP server gives Cursor the capability. A Cursor Rule gives it the behavior. I created .cursor/rules/lovable-design-handoff.mdc with roughly this content:
1Use the existing Lovable project [PROJECT ID]2for UI/UX design exploration.3 4The local Cursor repository is always the source of truth.5 6When I ask for visual redesign, UI exploration,7page redesign, component styling, or UX exploration:8 91. Inspect the existing local implementation first.102. Understand its functionality, components, and constraints.113. Send the relevant design task and context to Lovable.124. Do not create another Lovable project.135. Let Lovable explore the design.146. Retrieve the resulting project state, preview,15 screenshot, and relevant diff.167. Compare the Lovable result against the local repository.178. Present the proposed direction to me.189. Do not modify the local repository until I approve it.1910. After approval, implement only the approved parts locally.20 21The local Cursor repository remains the source of truth.That rule is probably my favorite part of the setup. It changes Lovable from “another AI tool Cursor happens to know about” into “the design specialist assigned to this project.” That is a much stronger abstraction.
What using it actually feels like
Now I can stay inside Cursor and say: “Give this screen to Lovable. Have it explore a more premium visual direction. Keep the existing functionality. Do not modify my local code yet.”
Cursor can first inspect the current implementation. That means the brief going to Lovable can contain real context from the application rather than my vague recollection of how the screen works. Lovable then gets to do what it is good at: explore the visual solution.
Once it is done, Cursor can inspect what came back. I can say: “Show me what Lovable changed. Tell me which parts you think are worth bringing into our current implementation.” Or: “I like the card layout and typography. I don’t like the navigation changes. Implement only the card treatment locally.”
That interaction is exactly what I wanted. Not generate → overwrite, but generate → inspect → judge → selectively adopt.
Plan first, build second
Lovable’s MCP workflow also supports a planning mode. For larger redesigns, that gives me an even better loop. Instead of immediately telling Lovable to start modifying the design, I can have Cursor ask it to think through the problem first:
Ask Lovable in plan mode how it would redesign this screen. Focus on information hierarchy, spacing, interaction patterns, and visual polish. Do not build anything yet.
Now the workflow becomes: existing implementation → design discussion → proposed direction → my approval → Lovable builds → Cursor reviews the result. This sounds obvious, but separating “What should we do?” from “Go build it” makes AI-generated design work noticeably easier to control.
Cursor stays the source of truth
This is the architectural decision I care about most. My local repository remains authoritative. I don’t want the application to gradually become a collection of whatever several AI tools independently decided to generate.
Lovable can rethink the interface. Cursor is responsible for reconciling that design with the real application. That means Cursor can preserve things like existing state management, APIs, business logic, component contracts, naming conventions, analytics, error handling, accessibility decisions, and architecture — while still borrowing the best visual ideas from Lovable.
That feels much closer to the relationship between engineering and design on a real team. A designer explores a solution. Engineering evaluates how that solution fits into the actual system. Then the two get reconciled. The AI version should work the same way.
The security detail worth knowing
So putting a specific project ID into my Cursor Rule is a workflow constraint — it is not a hard permission boundary. That matters. I would not treat agent instructions as a replacement for proper permissions, and I would be careful about blindly auto-approving every MCP action.
The other thing worth noting is that Lovable currently labels the MCP server as a research preview, so I would expect the details of the integration to evolve. This article reflects the workflow as I’m using it in September 2026.
The bigger idea is more interesting than the integration
The part I like most about this setup actually has very little to do with Cursor or Lovable specifically. It is the idea of specialized agents working together.
Most AI development products are still framed as complete destinations: build the app here, design the app here, research here, deploy here. But I think the more interesting future looks like one lead agent coordinating a design specialist, a data specialist, and an infrastructure specialist.
The lead agent does not need to be the best at every task. It needs to understand the goal, understand the system, know which specialist to call, and know how to reconcile the result. That is essentially what I’m doing here: Cursor owns the application context, Lovable gets called when the problem becomes visual, and I decide what gets accepted.
It is simple orchestration, but it feels surprisingly close to how I expect AI-native software teams to work.
My workflow today
1Build in Cursor2 ↓3Identify a UI/UX problem4 ↓5Cursor inspects the existing implementation6 ↓7Delegate the design task to Lovable via MCP8 ↓9Lovable explores the design10 ↓11Cursor retrieves and evaluates the result12 ↓13I approve, reject, or refine it14 ↓15Cursor implements the approved parts locally16 ↓17Continue buildingThe integration disappears into the workflow very quickly. I no longer think “I should open Lovable and recreate this screen over there.” I just say “send this one to Lovable” — and Cursor handles the handoff. That is exactly what I wanted.
Final thought
I think there is a temptation with AI coding tools to keep looking for the one platform that will do everything best. I’m becoming increasingly convinced that is the wrong model. The more interesting setup is: one source of truth, multiple specialists, clear handoffs, and human approval where it matters.
For me, Cursor + Lovable over MCP is one of the first workflows where that starts to feel genuinely natural. And once the setup is done, it barely feels like an integration at all. It just feels like having another person on the team.