Using Lovable's MCP server from Claude Code or Cursor

TL;DR. The Lovable MCP server is a remote endpoint at https://mcp.lovable.dev that signs you in with OAuth and exposes your Lovable workspace as tools: create projects, send prompts to Lovable's agent, read files and diffs, query a project's Cloud database, deploy. Add it to Claude Code with claude mcp add --transport http lovable https://mcp.lovable.dev, or paste Lovable's mcpServers block into Cursor's mcp.json. Lovable's agent still writes the code and Lovable's credits still meter the builds, as of August 2026. The alternative is to connect Claude Code or Cursor to Hatchable, where the same agent builds and deploys the app itself, with a database and a live URL and no credits.

What the Lovable MCP server is

Lovable released an MCP server in 2026 that lets an outside AI client drive a Lovable account. Based on Lovable's documentation as of August 2026: it is a remote server using the Streamable HTTP transport at https://mcp.lovable.dev; authentication is OAuth only (a browser sign-in on first use, no API key); and it exposes roughly sixty tools grouped into projects and workspaces (list_projects, create_project, deploy_project, remix_project), agent interaction (send_message, get_message, list_messages), code inspection (list_files, read_file, get_diff), knowledge and skills, the Cloud database (enable_database, query_database), connectors, analytics and file uploads. Lovable lists ChatGPT, Claude, Claude Code, Cursor and VS Code as supported clients, says the server is available on every plan including Free, and notes that the connected client has the same account access you do. Enterprise workspaces have to switch on third-party MCP clients first.

Two details shape everything below. First, the tools do not edit code directly: send_message hands a prompt to Lovable's own agent, which does the building, and the outside client polls for the reply. Second, Lovable's docs state that create_project and send_message consume standard Lovable credits while the other tools are free, so the metering of your Lovable plan applies through MCP exactly as it does in the browser.

Add it to Claude Code

1. Register the server

   From any terminal:

   claude mcp add --transport http lovable https://mcp.lovable.dev

   Add --scope user if you want it in every project rather than the current directory. Lovable also publishes a plugin (/plugin install lovable@claude-plugins-official inside Claude Code, per its docs) that registers the server and adds slash commands; the plain claude mcp add route is enough.

2. Sign in when prompted

   The first time a Lovable tool runs, Claude Code opens a browser tab for Lovable's OAuth flow. Approve it and the token is stored for later sessions.

3. Verify

   claude mcp list

   lovable should show as connected. Remove it later with claude mcp remove lovable.

Add it to Cursor

1. Open Settings, Cursor Settings, MCP

   Choose Add new MCP server, or edit ~/.cursor/mcp.json directly (.cursor/mcp.json in a repo for project scope). Cursor 1.0 or later handles OAuth over Streamable HTTP.

2. Paste the server block

   This is the entry Lovable's docs publish as of August 2026, including the public client ID they ask Cursor users to include:

   {
     "mcpServers": {
       "lovable": {
         "type": "http",
         "url": "https://mcp.lovable.dev",
         "auth": { "CLIENT_ID": "6d465f583e1e4ce5801b1616f735670c" }
       }
     }
   }

   If you already have other servers, add the lovable object inside your existing mcpServers.

3. Save and approve

   Cursor re-reads the file, opens the OAuth tab, and the MCP page shows the server with a green connected indicator once you have signed in. Lovable also offers a Cursor plugin with /lovable- slash commands, which does the same wiring with a guided setup.

What a session looks like

Ask Claude Code or Cursor's agent something that needs Lovable:

"Create a Lovable project for a habit tracker with a weekly view, wait for it to finish, then read the main page file and tell me what it built."

The client calls create_project (one credit-consuming step), then send_message with the build prompt, polls with get_message or list_messages until Lovable's agent replies, then list_files and read_file to pull the code into its own context and summarise it. Follow-ups ("add a streak counter") are further send_message calls; get_diff shows what changed; query_database runs SQL against the project's Cloud database if it is enabled; deploy_project publishes. Your local agent is the orchestrator and reviewer. Lovable's agent is the one writing the app.

What it is good for

• Working across many projects. Listing, remixing, deploying or moving projects in bulk from one terminal instead of clicking through each.
• Reading Lovable code into a local context. Pull files and diffs next to your other repos so Claude Code or Cursor can reason about the whole picture, or write a spec before handing a prompt back.
• Data checks from the terminal. Querying a project's Cloud database without opening the Lovable UI.
• Scripted iteration. Letting a planning-strong agent drive a sequence of prompts and verify each result, which is tedious by hand.

The trade-off: one AI driving another

Be clear about what you are paying for. You already pay for Claude Code or Cursor. Through this server you also spend Lovable credits on every create_project and send_message, under Lovable's plan limits, which as of August 2026 include a capped free tier and paid tiers with monthly credit allotments (see Lovable's pricing page for current numbers). Latency doubles, because each step is a round trip through a second agent. The code lives in Lovable's project, so your local agent reads it but does not own the edit loop; when Lovable's agent misunderstands a prompt, the fix is another prompt, not a patch. And the part of Claude Code or Cursor you chose them for, the coding itself, mostly sits idle.

None of that makes the server a bad idea. If your apps are already in Lovable and you like its UI defaults, it is a clean way to operate them from the tools you live in. It is a poor fit when the thing you actually want is for your own agent to write and ship the app.

The other path: the same agent builds and deploys on Hatchable

Connect Claude Code or Cursor to Hatchable's MCP server instead and the division of labour disappears. Your agent creates a project, writes the files (HTML, JS, SQL, TOML), runs migrations against the project's private Postgres, deploys, and hands back a live URL at your-app.hatchable.site. Sign-in for the app's users, file storage, email, scheduled jobs and a headless browser are in every project. There are no credit packs and no per-prompt fees: your existing AI subscription writes the code, and the free plan includes unlimited private projects and one published app, no card. Builder is a flat $12 a month for unlimited published apps.

claude mcp add --transport http hatchable https://hatchable.com/mcp

For Cursor, the one-click installer on the connect Cursor page adds https://hatchable.com/mcp and runs the same OAuth flow; the connect Claude Code page covers the CLI route above. If you are weighing the two products rather than the two workflows, the Lovable alternative page and the head-to-head go into UI quality, credits and portability.

Lovable details are general characterisations based on public information as of August 2026; check Lovable's documentation for current commands, tools and plan limits.