Lovable MCP: Connecting MCP Servers to Your App and Workflow

What is MCP, and what does "Lovable MCP" actually mean?

MCP — the Model Context Protocol — is an open standard for connecting AI applications to external tools and data, described as a "USB-C port for AI applications." In Lovable, MCP runs in two opposite directions: a chat connector lets the Lovable agent reach into your tools during a build, and the Lovable MCP server lets an outside AI client reach into Lovable and drive it.

The confusion is worth clearing up before you configure anything, because the two directions have different setup, different auth, and different use cases. A chat connector is inbound context: the Lovable agent connects to an MCP server you point it at (Notion, Linear, or your own custom server) and reads structured data so it can generate more accurate code and prototypes.

The Lovable MCP server is outbound control: Lovable exposes itself as an MCP server at mcp.lovable.dev, so an external client — ChatGPT, Claude, Claude Code, Cursor, or VS Code — can create projects, iterate on them, inspect code, and deploy, all without opening the Lovable UI. Same protocol, opposite direction.

Related: the Integrations & APIs hub

What are the two ways MCP connects to Lovable?

Decide by which side is the client. If you want Lovable to use your tools while building, add a chat connector — Lovable is the client and your MCP server provides context. If you want an AI assistant or editor to control Lovable, connect it to the Lovable MCP server — the external client is the client and Lovable is the server. The table below maps each to its setup and auth.

Related: Lovable's own Shopify-style API integrations

How do I connect a custom MCP server to Lovable as a chat connector?

Open Connectors, choose the Custom MCP option, and give Lovable your server's URL and an auth method. Once connected, the Lovable agent can read structured context from that server during builds — and, where the server supports it, perform limited actions. Lovable ships prebuilt connectors for tools like Notion, Linear, Atlassian, Miro, Sentry, and PostHog, plus support for any custom MCP server.

1. In your Lovable project, open Connectors and go to Chat connectors.
2. For a prebuilt tool, select the connector (for example Notion or Linear), click Connect, then sign in and authorize Lovable's access.
3. For your own server, select the Custom MCP option and enter a clear Server name (for example, Internal CRM).
4. Enter the Server URL where Lovable can reach your MCP server.
5. Choose an authentication method: OAuth (the default, with an authorize prompt), a Bearer token or API key for servers without OAuth, or No authentication if the server needs none.
6. Click Add server; the connector then appears in your list and can supply context to future builds.

How do I connect an external AI client to the Lovable MCP server?

Add https://mcp.lovable.dev in your AI client's MCP or connector settings and authenticate with OAuth — there are no API keys to manage. Lovable supports ChatGPT, Claude, Claude Code, Cursor, and VS Code. Once connected, your assistant can create a project, send iteration messages, inspect files, and deploy, using your existing Lovable permissions.

A manual Cursor or VS Code configuration is a small JSON block that names the server and its HTTP endpoint:

{ "mcpServers": { "lovable": { "type": "http", "url": "https://mcp.lovable.dev" } } }

Because authentication is OAuth against your own Lovable account, the MCP server can only touch workspaces you already have access to — it inherits your permissions rather than granting new ones. Lovable notes that API-key authentication is not currently supported for this server.

1. In your AI client, open its MCP or connector settings (for example, Claude's Connectors panel or Cursor's MCP configuration).
2. Add a new server with the URL https://mcp.lovable.dev and the HTTP transport type.
3. Complete the OAuth flow when prompted — the client opens a browser window to sign in to your Lovable account.
4. Confirm the Lovable tools now appear in the client's tool menu.
5. Drive Lovable in natural language: create a project, iterate on it, read the code, and deploy — all from the client you already use.

What are MCP's core primitives and transports?

MCP defines three server primitives — tools, resources, and prompts — exchanged over a JSON-RPC 2.0 data layer. Tools are executable functions an AI can invoke; resources are data sources that provide context; prompts are reusable interaction templates. Two transports carry them: stdio for local process communication and Streamable HTTP for remote servers, which is what a hosted server like mcp.lovable.dev uses.

Understanding the primitives helps you reason about what any MCP integration can and cannot do. A server exposes tools the agent can call, resources it can read, and prompts it can reuse; the client discovers them dynamically with list methods and invokes them by name. That discovery model is why you can connect a new MCP server and immediately see its capabilities without hardcoding anything.

Transport matters for security. The Streamable HTTP transport supports standard HTTP authentication — bearer tokens, API keys, and custom headers — and MCP recommends OAuth to obtain those tokens, which is exactly what Lovable does for its own server. A local stdio server, by contrast, runs on the same machine with no network hop, which is common for developer tooling.

Related: why keyed API calls belong in an edge function

How do I keep an MCP integration secure and production-ready?

Prefer OAuth over static tokens, keep any bearer token or API key on the server, and grant the narrowest access the integration needs. For chat connectors, remember the connection carries your tool permissions into the build; for the Lovable MCP server, the OAuth link can create and deploy projects. Review connected clients and connectors regularly and revoke anything unused.

When you connect a custom MCP server that authenticates with a bearer token or API key, that credential is a secret — it belongs in a server-side environment, never in front-end code or a VITE_ prefixed variable that gets bundled into the public app. This is the same discipline that keeps a Stripe or Shopify token out of the browser, applied to MCP.

For anything customer-facing or revenue-adjacent that an MCP-driven workflow touches, add the usual production guardrails: verify inputs, make actions idempotent, and log what the agent did. MCP makes it easy to wire powerful tools into a build quickly, which is exactly why the production hardening around those tools should not be skipped.

Related: Lovable env & secrets best practices

When should I bring in an engineer for an MCP workflow?

Bring one in when an MCP integration moves from convenience to dependency — when a custom server drives real actions, when an agent can deploy or write to your database, or when a workflow needs to be reliable rather than exploratory. MCP wires capabilities together fast; making that wiring safe, observable, and idempotent is the productionizing work that keeps it from breaking quietly.

A specialist scopes what each connected server can do, keeps credentials server-side, adds verification and idempotency around any tool that writes data, and builds the reconciliation and logging that turn a demo-grade automation into something you can trust in production. That is the gap between an MCP integration that impresses in a demo and one that survives real use.

If you have chained several MCP tools into a Lovable workflow and it works until it does not, that is the signal to harden it rather than re-prompt it. We productionize MCP-driven builds so the automation is dependable and the access is scoped — see the service below.

Related: productionize a Lovable app and its integrations · book a build review call