Lovable MCP: Three Things With One Name

"Lovable MCP" is three different features in Lovable's docs right now (checked October 29, 2026), and people mix them up constantly. The Lovable MCP server at https://mcp.lovable.dev lets an AI client like ChatGPT, Cursor or VS Code drive your Lovable projects. Chat connectors go the other way: Lovable's agent reads from your MCP servers while it builds. And agent integrations turn your published app into an MCP server that other people's assistants can call.

They point in different directions, they cost different things, and only one of them touches your live users.

	Who calls whom	Plans	What it costs
Lovable MCP server	Your AI client calls Lovable	All plans	Normal credits for every message and build it triggers
Chat connectors (custom MCP)	Lovable's agent calls your tools while you build	All plans	Nothing extra to connect; it's context for builds
Agent integrations	Someone's assistant calls your published app	All plans for public apps	Build credits to set up, then normal backend and AI usage per call

1. The Lovable MCP server: driving Lovable from somewhere else

This is the one most searches mean. Lovable runs an MCP server at https://mcp.lovable.dev, login is OAuth, and it's on by default for Free, Pro and Business workspaces (Enterprise admins have to switch on "Third-party MCP clients" first). In ChatGPT you paste the URL; in Cursor and VS Code it's a few lines in mcp.json; Claude Code has a one-line mcp add command. The Lovable MCP server docs have the exact config for each.

Once connected, your client gets about forty tools. The useful ones: create_project, send_message (with a plan_mode switch), get_diff, list_files, read_file, list_edits, deploy_project, get_project_analytics, and three database tools, get_database_status, enable_database and query_database.

Where it's genuinely good: reading code and diffs without opening the editor, asking for three layout variants and getting three live URLs back, and pulling analytics into the same chat where you're already working. I like get_diff most. Being able to ask "what did the last three prompts actually change" and get a unified diff is the review step Lovable never had.

Read Lovable's own warning box before you connect it, because it's blunt for a reason:

• The connection isn't limited to one project. It can reach every workspace your account can.
• Tool calls spend real credits. An agent that loops on send_message because it doesn't like the result will burn through a month's credits while you're making coffee. Same credit pool as the editor, same prices.
• deploy_project publishes for real. On Free and Pro, anyone with the link can open the app unless website access is set to invite only.
• query_database runs SQL with your full database permissions. Reads, writes, drop table.

My rule: the MCP server is fine for building and reviewing. I wouldn't hand query_database on a production project to any agent that runs without a human reading each call.

One more detail that surprises people. The database tools only work on Lovable's built-in Cloud database. If the project uses your own Supabase project, Lovable's docs say it's "managed in Supabase instead", so you'd connect Supabase's own MCP server for that. That's one of the small reasons teams move from Lovable Cloud to their own Supabase: the database becomes something every tool can reach, not just Lovable.

The MCP server is also the only way to create and edit projects from outside. The Lovable API can publish, embed and read analytics, but it can't send a prompt.

2. Chat connectors: Lovable reading your tools

The second "Lovable MCP" is the reverse. You give Lovable's agent access to a remote MCP server (Notion, Linear, Jira, or your own) so it builds from real context: "use the spec in the Notion page" instead of you pasting it.

Custom MCP servers work on all plans. You add them under Connectors, Add custom, MCP server; auth is OAuth by default, or a bearer token, or none. If your server sits behind a firewall, there's a "Lovable static IPs" option that routes traffic from 185.41.150.0/28 and 185.41.150.16/28 so you can allowlist them. Details are on the custom MCP page.

The trap: chat connections are personal and "never part of your published app." Connecting your CRM as an MCP server doesn't let your app read the CRM. That needs an app + chat connector, a different feature with different credentials. It's an easy mistake to make, because the agent uses the connector perfectly in chat, and then the live app still can't see a thing.

3. Agent integrations: your app as an MCP server

The newest one, and the one I'd slow down on. Lovable can turn a published app into an MCP server: it reads your app, proposes tools like list_open_requests or generate_quote, asks whether callers must sign in, and gives you an MCP link users add to ChatGPT or another assistant. The agent integrations docs cover the setup.

Lovable doesn't charge for hosting the integration or for tool calls. Enabling it is a build, so it uses build credits, and every call after that costs what the action behind it costs: database reads, Cloud usage, AI calls. Free and Pro apps have to be published publicly to get one. Sign-in needs real app auth, and on newer TanStack Start apps with your own Supabase project, Lovable turns on Supabase's OAuth 2.1 server when you publish.

Then there's this line from the docs, which is the whole reason this section exists: agent integrations "do not include a built-in rate limit or spending cap."

Think about what that means for a tool that calls an AI feature. A person clicks a button a few times. An assistant in a retry loop calls generate_quote a few thousand times, and every call runs your real backend and your real AI usage on your credits. If the tool is open to anyone, it doesn't even need an account to do it.

Before I'd switch one on for a live app:

1. Start with read-only tools. Nothing that writes, sends email or charges a card.
2. Require sign-in unless the data is already public on your site.
3. Put a per-user limit in the backend function itself, because nothing else will.
4. Make every write safe to run twice, since assistants retry.
5. Check that each tool enforces the same RLS policies and plan checks as the screen it replaces. Lovable proposes tools from what the app does, not from who's allowed to do it.

That last one is exactly what we look at in a Lovable security audit: an app that's safe through its own screens can be wide open through a second door nobody tested.

Which one did you actually want?

If you want to build or review Lovable projects from ChatGPT, Cursor or VS Code, it's the MCP server. If you want Lovable to read your docs and tickets while it builds, chat connectors. If you want your customers to use your app from inside their assistant, agent integrations, with limits you add yourself.

And if the credit side of any of this worries you, our free Lovable cost check reads your repo and prices the app four ways, including running it outside Lovable. For the app itself, tell us what you're building.

---

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.