Lovable's ChatGPT and Claude Integration: What Founders Should Scope Now
Lovable can now expose a published app to ChatGPT and Claude via MCP. Here is the narrow, secure MVP scope founders should ship first.
Lovable's new agent integrations are useful when your product already has one repeatable, permissioned action that users want to trigger from ChatGPT or Claude. Ship that action read-first; do not expose your whole app and call it distribution.
The verdict: ship one assistant-native job or wait
Add the integration when a user can finish a core job faster from an AI assistant than from your interface. A quoting product that can retrieve a customer's open estimate, apply approved pricing logic, and prepare a draft has a credible assistant-native job. A portfolio, game, or visual analytics product whose value lives in exploration does not.
The distinction matters for an MVP, the smallest launchable product that proves one core workflow with real users. An MCP endpoint is another product surface to secure, test, explain, and support. It earns that scope only when it shortens an existing job, not when it merely adds an AI-shaped checkbox.
What Lovable actually changed
Lovable can now generate and host an MCP server for a publicly published app. Model Context Protocol, or MCP, is an open standard that gives an AI assistant a list of actions it can call as tools. The assistant sees only the tools you publish, while your live app still performs the work and returns the result.
The July 15 release is available on all Lovable plans, but only for publicly published apps. The app also needs a backend through Lovable Cloud or a connected Supabase project. A connected Supabase project needs its OAuth 2.1 authorization server enabled before Lovable can build a protected integration. Workspace and internal apps are not supported yet. Lovable's agent integration documentation carries the current prerequisites.
Lovable proposes tools from the app's existing logic, lets you edit that list, hosts the remote server, and keeps it aligned with the published app. Protected OAuth access is the default. Public access without sign-in is an explicit choice, not an accidental side effect of publishing the website.
That is useful plumbing. It is not automatic product judgment. You still decide which jobs deserve tools, what each tool may return, who may call it, and what happens when a call fails or repeats.
Do not confuse Lovable's three MCP directions
Use agent integrations when customers should act on your published product from an assistant. Lovable now uses MCP in three distinct directions, and choosing the wrong one produces the wrong scope.
The new release is the first row. It does not give customers access to your Lovable editor or project. It gives their assistant a controlled route into actions on the published app.
This boundary should shape the product language too. Tell users the specific action the connector performs, such as "check an open request" or "prepare a quote." Do not market it as a second copy of the application.
The first scope should be read-first and narrow
Start with a small set of focused, read-only tools, then add a write action only after the access and retry paths are proven. Lovable recommends this order because read tools can still leak data, while write tools add duplicate, destructive, and paid-resource failure modes.
Consider an illustrative B2B quoting product. Its first useful assistant job is not "manage sales." It is "find the signed-in user's open quote and explain its current status." That can be scoped as a narrow lookup with a record identifier, an ownership check, and a minimal response containing only the status and next required action.
Name the user job
Write one sentence with a user, an action, and a result: "An account manager checks an open quote and learns what is blocking approval." If the sentence contains several jobs joined together, split it before building.
Expose the read path
Create a clearly named tool such as
get_quote_status. Accept a specific quote identifier, enforce the signed-in user's account access in the backend, and return only the fields required to answer the question.Add a reversible write
After the read path is reliable, add a tool such as
draft_quote_revision. Keep it as a draft, require the same role and plan checks as the product, and make repeat calls return the existing draft instead of creating duplicates.Test the denied paths
Run the tool as an ordinary user, as a user without the required role, with another account's record identifier, and twice with the same request. A successful happy path is not enough evidence for launch.
The write action must be safe to retry. Assistants can repeat a call after a timeout or connection error, so a create operation needs an idempotency rule, meaning the same request cannot create the same record twice. A request identifier or a lookup for an existing draft can supply that rule.
ChatGPT and Claude are not the same launch surface
Validate the connector in the assistant your customers can actually use, because current plan and admin gates differ. "Works with ChatGPT and Claude" describes protocol compatibility, not identical distribution.
OpenAI's current MCP app guidance also says ChatGPT keeps a frozen snapshot of approved tools until an admin reviews and publishes an update. Anthropic's current connector guidance says Claude Free users get one custom connector and warns teams to review permissions and prompt-injection risk.
For a funded B2B product, this changes the pilot design. Recruit users from a workspace where the connector can be approved, document the exact install path, and measure completion of the target job. Do not count an MCP link as distribution before a customer can authorize and use it.
The real launch gate is cost and permission control
Ship only after the backend can enforce identity, entitlements, and usage without relying on the visible interface. Lovable does not charge a separate fee for hosting, publishing, or calling the integration, but every tool call still consumes the app's normal database, Cloud, AI, and third-party resources. There is no built-in rate limit, spending cap, or tool-call quota.
For the quoting example, a generate_quote action that calls a paid model and a pricing service needs more than OAuth. The backend should confirm that the user owns the account, has the required plan, remains within the product's usage policy, and may access every returned field. A hidden button or an unlisted page does not enforce any of those rules because MCP calls bypass the screens.
Use this launch gate:
- Identity: Keep protected OAuth on unless every active tool and returned field is safe for anonymous use.
- Authorization: Enforce record ownership, role, plan, and permission checks inside each backend action.
- Data minimization: Return the smallest field set that completes the job.
- Retry safety: Make every modifying action safe when the same request arrives again.
- Usage control: Apply your own per-user or per-plan limit before a tool can consume a paid service.
- Observability: Log the user, tool, request identifier, result, latency, and error without storing sensitive payloads unnecessarily.
Lovable runs a basic security check at every publish and a deeper scan when an unauthenticated public integration is published or changed. Those checks help, but they cannot infer every custom business rule. Run denied-user, wrong-record, repeated-call, and paid-limit tests yourself before sharing the connector.
If the underlying code and ownership path are still unclear, use the Lovable production handoff checklist before adding another surface. An integration should sit on a product you can inspect, deploy, and maintain.
What this release does not solve
The feature removes MCP hosting work, not the hard parts of distribution and production behavior. Keep these limits in the decision:
- No discovery directory: You distribute the MCP link and teach users how to connect it.
- No proactive alerts: The integration cannot contact an assistant on its own; it acts when a user asks.
- No safe default for long jobs: Work that takes more than tens of seconds can appear stuck or interrupted. Trigger heavy work quickly inside the app and expose a separate status check.
- No mixed public and protected tool set: Access applies to the whole integration, although protected actions can enforce different roles and plans.
- No automatic client refresh: Users must refresh their connector after you add, remove, or rename tools.
That still leaves a valuable product surface: one clear job, called from a place the user already works, with the app's real rules behind it. It just needs the same scope discipline as the rest of the MVP.
Frequently asked questions
What is the Lovable MCP server?
For this release, it is a hosted endpoint that exposes selected actions from a publicly published Lovable app to compatible assistants. It is separate from the Lovable MCP server that lets external AI tools create, inspect, and deploy Lovable projects.
Does Lovable work with Claude?
Yes. Users can connect the published app's remote MCP link in Claude. Custom remote connectors are currently in beta across Claude Free, Pro, Max, Team, and Enterprise, with owner controls for Team and Enterprise organizations.
Can I use a Lovable app inside ChatGPT?
Yes, subject to ChatGPT's current plan and workspace controls. Full MCP with write actions is rolling out to Business, Enterprise, and Edu on web; Pro currently supports read and fetch connections in developer mode.
Is the Lovable Claude API the same as agent integrations?
No. The new connection is a remote MCP server that compatible assistants can call. It is not an API that embeds Claude in the app, and it is not the separate Lovable MCP server used to edit a Lovable project.
Will a Lovable agent integration expose private data?
Protected OAuth access is the default, but sign-in alone is not enough. Every tool must enforce ownership, role, permission, and plan rules in the backend and return only the fields its job requires.
Does Lovable charge for MCP tool calls?
Lovable does not charge a separate integration-hosting or tool-call fee. The action still consumes the app's normal backend and third-party resources, and the integration has no built-in spending cap.
Scope Your MVP Sprint
Turn the useful assistant workflow into a fixed-scope product with real auth, usage controls, payments, a launch site, and full code ownership.
Jul 17, 2026
