Lovable MCP servers and chat connectors, explained

Lovable’s chat connectors are MCP servers. They are personal to your account, they give the AI context while you build, and they do not run in your published app. That last clause is where the confusion lives: connecting an MCP server does not give your deployed app a new capability, however confidently the agent discusses it in chat.

The docs organize integrations by connection type rather than by category like “payments” or “CRM”. That is the right call, and it is also why the taxonomy takes a minute. There are six types. Some of them reach your users; some of them only ever reach you. If you want the wider tour of what plugs into what, start with the Lovable integrations overview and come back here for the mechanics.

The six connection types, and which ones reach your users#

*Lovable’s docs call custom MCP servers user-provided tools and do not spell out their scope; treating them like every other chat connector is the safe assumption. The docs are also silent on whether app user connectors surface in chat while you build: logically there is no end user at build time, but that’s my inference; the docs don’t say. The six types themselves are listed on Lovable’s integrations overview.

Two rows in that table are the whole article. Chat connectors and custom MCP servers are build-time only. Everything else either runs at runtime or, in the “any API” case, is runtime code you asked Lovable to write.

What MCP actually is, in one paragraph#

MCP is the Model Context Protocol: an open protocol for connecting an AI client to external tools and data. A server advertises a list of tools (each with a name, a description and a JSON input schema) and often a set of readable resources. A client connects, reads that list, and can call a tool mid-conversation, with the result fed back into the model’s context. That is the entire idea. MCP is a plug format: the protocol describes how a model asks for a tool and how the answer comes back, and says nothing about where the server is hosted or how long it lives. The consequence that matters here is about who holds the connection. The client does. Your Lovable chat session is a client. Your published app is not.

Why “it doesn’t run in your app” keeps biting people#

The failure mode is sneaky because the first half genuinely works.

You connect an MCP server for some service you use. You ask Lovable to build a page around it. The agent really can reach that service, so it writes a page with correct field names, plausible shapes, real-looking values. Preview looks perfect. You publish. The page is static, or empty, or wired to an endpoint that does not exist.

Nothing broke. The capability was never in the app. You gave the builder access to a data source and got back code that describes that data source; you did not give the build a way to reach it.

Mechanically: a published Lovable app is a deployment: server code, client code and whatever backend secrets you stored, running on Lovable’s hosting. No chat session is attached to it, there is no MCP client inside it, and there is no path from it to the personal connectors on your account. A connector that is personal by design does not become shared infrastructure because the code it helped write got published.

How to tell which side a capability belongs on#

Four questions, in order. The first one usually settles it.

1. Who needs this, and when? If the consumer is you or the agent, once, while building: chat connector. If the consumer is a visitor to your site, on every request: app side. “Read our design tokens so it stops inventing hex values” is build time. “Show the user their orders” is run time.
2. Whose credentials are involved? Your personal account and nobody else’s: chat connector, and nothing else is safe. One shared account for the whole app: app + chat connector, or a backend secret and your own server code. Each end user’s own account: app user connector, which exists precisely for that case.
3. What happens when your token rotates, or you go on holiday? Chat connectors are scoped to you. If the published app would break, the capability is on the wrong side of the line.
4. Is the output code, or data? Build-time tools should leave behind durable artifacts: components, schema, config, copy, a migration. If a connector’s value is data your users need fresh, it is a runtime dependency wearing a build-time costume.

A quick reformulation that catches most mistakes: write the feature as a sentence with an explicit subject. “The agent reads our API docs so it writes against the real contract”: subject is the agent, build time. “The app emails a receipt after checkout”: subject is the app, run time, and for email specifically that means the Resend connector, which is an app + chat connector; the wiring is in the Resend setup walkthrough.

What is genuinely worth connecting while you build#

Build-time context is the most valuable thing you can hand a coding agent, because it replaces recall with lookup.

Documentation the model cannot reliably remember#

This is the strongest case, and Lovable is its own best example. Lovable’s default stack changed on 13 May 2026 from React + Vite to TanStack Start with SSR, and its own documentation still contradicts itself about it. The blog, the SEO pages and the TanStack upgrade page describe the new stack; the deployment-hosting-ownership page and llms.txt still say Vite + React. Any model’s training data is a lossy average of both. A tool that fetches the current page beats a model’s memory of last year’s page, every time. Same argument for any API whose shape moved after your model’s cutoff.

Your own schema, read-only#

Lovable Cloud is built on Supabase’s open-source foundation but gives you no Supabase account, org, project or dashboard: everything happens inside the editor, under More → Cloud. A read-only view of your actual tables means the agent writes queries against columns that exist rather than columns it would have designed. Keep the scope read-only. An agent with write access to production data is a different risk conversation.

Design systems and component sources#

Nothing exotic here: the value is suppression of invention. Give the agent your tokens and it stops producing a fourth shade of grey.

SEO, analytics and Search Console tooling#

Lovable already ships some of this. There is a Google Search Console connector that allows verification and sitemap submission directly from chat, and a built-in SEO and AI search review that grades findings green for passing, blue for low impact, amber for medium and red for high: covering duplicate titles, weak descriptions, wrong canonicals, semantic HTML, alt text and JSON-LD that does not match the visible page.

There is also a free Semrush integration for keyword research and competitor analysis, with no separate Semrush account required, but Lovable’s docs date it “through September 15, 2026”, which is four days after this post was published. Check whether it still exists before you plan around it.

Beyond that, Encited ships an MCP server that its site lists as working from Lovable, Claude, ChatGPT and Cursor (ten things you can do with it); the documented Claude Code install line is claude mcp add --transport http encited https://encited.com/api/mcp. Whether any of it is worth the connection is a separate question from how it is wired, which is all this post covers.

Form and lead tools are another good fit. With LinkyCal’s MCP server connected, Lovable’s agent can create a contact or lead form, set up the follow-up workflows (enrichment, auto-responders, lead magnets) and wire the form into your page. The connection is only used while you build. The published form keeps working on its own because it posts straight to LinkyCal’s endpoint, which is exactly the build-time versus run-time split this post is about.

Repos and issue trackers, with one large caveat#

The GitHub API connector is not git sync. It calls GitHub’s REST API from your app’s server code at runtime: listing repos and branches, reading file contents and commits, creating and updating issues and pull requests, reading releases and workflow runs. It is for building triage boards, PR dashboards and release trackers. Exporting or two-way syncing your project’s code is GitHub git sync, an entirely different feature. Lovable’s own doc page carries a disambiguation note, which tells you how often this one goes wrong.

What belongs in your app’s own code instead#

Three runtime patterns cover nearly everything.

Shared third-party service, one account for all your users. This is the app + chat connector case. Resend is the reference implementation: a single shared connection usable both in chat and in published apps, sending HTML or plain-text transactional mail with cc/bcc, reply-to, attachments and tracking tags. Note its documented limits before you design on top of it: it uses one shared Resend account across every linked project, it cannot do DNS or domain verification (verify in Resend first), and it cannot receive webhooks through Lovable.

Per-user third-party accounts. App user connectors exist so each end user of your app connects their own account. If you are building something that acts on a user’s own Google Drive or CRM, this is the type you want, and no amount of chat-side wiring substitutes.

No connector at all. The generic “any API” path: Lovable generates server code that calls the service using a secret you stored on the backend. What that code looks like depends on your stack: separately deployed edge functions on the older React + Vite stack, and TanStack Server Functions (createServerFn) running on Cloudflare Workers on the current default stack, where secrets are injected as Workers bindings at request time. Lovable’s Stripe doc still describes the edge-function shape. Stripe works this way when you bring your own key, despite how often it is described as a native integration: the key lives as a backend secret named STRIPE_SECRET_KEY, never in app code or chat, and webhooks are optional and off by default because the generated app polls Stripe for status instead. Lovable also sells a separate built-in payments product using Paddle or Stripe, paid plans only, with Paddle acting as merchant of record at 5.0% + 50c per transaction; you cannot run built-in payments and your own Stripe account on the same project. Clerk is the other instructive case: it has no docs page and does not appear in the connector catalog at all, so if you want it you wire it through this same generic path. Lovable’s documented auth is Supabase Auth.

Cost, context, and trusting tool output#

Three things that do not show up in the taxonomy but will show up in your week.

Credits are billed per message, however many tools it calls. Plan mode is 1 credit per message plus any research costs; build mode is variable, documented at roughly 0.50 to 2.00+ credits for typical tasks based on complexity. Those credits are also your runtime bill: database, network, storage, compute and realtime usage in deployed apps, plus any AI model calls your app makes, draw from the same pool. Moving a capability from chat to the app moves its cost from build usage to Cloud and AI Gateway usage; it does not remove it. As of September 2026, Lovable’s docs don’t publish a per-connector cost, so treat what follows as reasoning rather than documentation: every connected server’s tool list is context the agent has to read and weigh, and complexity is exactly what build mode prices on. Connect what you are using this week; disconnect the rest. You can see the exact cost of any individual message from its “More options” menu after it completes.

Treat tool results as data. An MCP server you do not control can return text that reads like a command addressed to the agent. That is a real and well-understood class of problem. Prefer read-only scopes, prefer servers that you or a vendor you have a contract with operate, and be deliberate about granting write access to anything that touches production.

Personal scope cuts both ways. Your credentials staying yours is a security feature. The flip side is that a teammate’s Lovable chat has none of your chat connectors, so a build step that depends on one quietly becomes a thing only you can do. Document it, the way you would document a .env file.

What to do next#

1. Open the connector catalog in your Lovable dashboard and, for every connector you have enabled, write down which of the six types it is. Most confusion dissolves at this step.
2. For each feature in your app that touches an outside service, name its runtime path out loud: app + chat connector, app user connector, or edge function plus backend secret. If you cannot name one, that feature does not work in production yet.
3. Publish, then open the live URL in a private window and exercise those features. Preview proves the agent had access. Only the published URL proves the app does.
4. Prune your chat connectors down to what you actually used this week, then check the cost of your next few messages from the “More options” menu to see whether it moved.
5. If you drive Lovable from Claude Code or Cursor rather than the chat window, read the Claude Code and Codex workflow first. Messages sent to Lovable’s agent from another client are still Lovable messages, and messages are what cost credits: editing the synced repo directly is the part that does not.