You Can Now Create Your Own MCP for Your Lovable App (in Minutes)

Lovable shipped "agent integrations" this week: any publicly published app can expose its own MCP server, so ChatGPT, Claude, Cursor or any MCP client can use the app directly. The announcement tells you it exists. This guide covers what it actually changes: what "your app's own MCP" means, who can consume it (they don't need a Lovable account), how to design good tools, and how far you can take it.

First, what is MCP?

MCP (Model Context Protocol) is a bridge that lets AI assistants read and act on your app in real time. It's not magic: it's a clear contract of tools you expose so the AI can work with your data, your flow and your users. Think of it as a universal USB-C port for AI: instead of every assistant building a private integration with your app, your app publishes one standardized server and any compatible client plugs in.

The key property: the AI never queries your database on its own. It asks a tool, and the tool does the work: it runs the query, applies your rules, and returns only what you decided to expose. The AI talks to your tools, your tools talk to your data. Designing an MCP is designing that contract of conversation between your app and the AI.

Two MCPs, two jobs

Talking with builders since the launch, this is the confusion I keep running into: people mixing up the Lovable MCP with their app having its own MCP. They're different products solving different problems:

• The Lovable MCP (lovable.dev/mcp) is for building. Your agent talks to the platform: create projects, send prompts, deploy, query the database. One MCP, all of Lovable. Build time.
• Your app's MCP (agent integrations) is for using what you built. Each app exposes its own server, and the tools are the app's actual features. One MCP per app. Run time.

The mental model: the first one is the workshop, the second is the product you shipped, now operable by any assistant.

Here's the cleanest way to keep them straight: the Lovable MCP is Lovable doing this for its users: you connect your assistant and drive the platform. Agent integrations are you doing exactly the same for your users. Same move, one level down: Lovable made itself consumable from Claude; now your app can be too.

And that second one is where the opportunity is: your users can consume specific areas of your app through tools designed *for them*, with permissions and authorizations you control. That's a new value surface: your users use your app not only through the UI, but from Claude or ChatGPT, the interfaces where people are already spending their day, doing their work, and increasingly consuming their data.

Your app's MCP means letting others consume your app

That's the strict definition of the feature: third parties (your team, your clients, even other agents) can now use your app through their own AI assistant, without ever opening your dashboard. And "use" goes both ways: pulling information out (read) and sending information in (write).

How that looks in practice:

• Teams consuming your data, with differentiated access. If people in your team need data from your app, expose read tools and give each role what it needs: inside a protected integration, each tool can enforce its own role or plan check in your app's backend. Your accountant gets a reporting tool, your PM gets status tools, nobody gets everything.
• Teams sending data in. Say you run an agency and need your team to report how their day ended with each client. Expose a submit_daily_report write tool: the assistant interviews them ("which client? what shipped? any blockers?"), structures the report, and saves it. No form, no "I'll log it later".
• Your users chatting with their own data. Say you built an app where users log their daily cases. With an MCP, those same users can now review and chat with that data from Claude or ChatGPT ("how many cases did I close this week? which ones are still open?"), make decisions based on it, and even log new cases from the same conversation. I tested this with the app where my partner and I track our family expenses: we can see and chat with that data, ask how the month is going, and log a new expense without leaving the conversation.
• Clients following their projects. A client asks their own assistant "what's the status of my project?" or leaves structured feedback, without ever logging into your dashboard.
• A CRM. Your sales team asks "what happened with this account?", logs a call, or schedules a follow-up from the assistant, without opening the CRM.
• Other agents. Not just humans: an automated process can consume your MCP too, like an agent that checks every morning for new activity and writes a digest for your team.

The principle behind all of these: the easier you make it for people to consume information and to send information, the better the data you get back, and the more useful every other tool becomes.

One boundary worth stating: this doesn't replace your UI. The app is still the app. The MCP is an additional access channel you control: another door into the same product, for the people and agents you decide.

Read tools consume, write tools act

Every proposed tool comes labeled "Read-only" or "May modify data", and that label is the whole design decision:

• Read tools answer questions: list_items, get_status, summarize_round. Low risk, expose these first.
• Write tools change state: create_request, add_item, update_status. Each one is a door into your data. Add them deliberately, one at a time.

One server can expose both kinds at the same time. That's the normal shape, and it's what makes the agency example above work. Each individual tool stays one or the other: a tool either reads or it writes (and "writes" covers create, update and delete).

If you've heard the term CRUD, this is that: Create, Read, Update, Delete, the four basic things any app does with data. Your MCP is choosing which of those four verbs an assistant is allowed to perform, on which data, for whom.

Governance: who can consume your MCP?

The short answer: whoever you decide. The people calling your MCP are your app's users, not Lovable users. They don't need a Lovable account and they never see Lovable. Here are the possibilities:

• Your end users. Clients who live in chat, technical-but-not-designer reviewers, teams that track things by voice or text. They connect their assistant once and use your app from there.
• Your internal team. Designers checking feedback fast, PMs following up from their assistant, or role-specific consumers: your *accountant* connecting once to run "generate this month's sales report with transaction ids" against a reporting tool you exposed just for that role.
• Other AI agents. Scheduled processes and backend agents can call the same tools as humans do, and they go through the same access rules, so an agent gets exactly the permissions of the account it connects with.

And if your platform is multi-tenant or has different roles, you can go further: each person sees some things and not others. A client only sees their own projects, an admin sees everything, a team member sees their assignments. The same rules your app already enforces apply to the MCP. Which leads to the real takeaway of this section: design your MCP around who is going to use it. The tools your accountant needs are not the tools your clients need, and pretending one generic set serves everyone is how MCPs end up ignored.

The identity problem (read this before exposing any write tool)

When an assistant calls one of your tools there's no session, no cookie, no logged-in user from your app's point of view. So for any write tool the first question is: who is acting?

• Public + identity as a parameter. The tool accepts an email as an argument. Fast, and completely unverifiable: anyone on the internet can write data signed as anyone else. For anything where "who said what" matters, this quietly destroys the record.
• OAuth (sign-in required). The user connects their assistant once, signs in as their real app user, and from then on the assistant acts *as them*: the user id comes from the token, not from a parameter, and your RLS policies apply exactly as in the app. This is the default: if you don't answer the access question when enabling, Lovable uses protected access.

Prerequisites worth knowing: OAuth mode needs real Supabase Auth in your app. If your app "authenticates" with something lighter (an email allowlist, a localStorage gate), enabling a protected MCP means migrating that login first. On Lovable Cloud the OAuth server comes pre-configured; if you connected your own Supabase, you have to enable the OAuth 2.1 authorization server in your Supabase dashboard and reconnect the project. Also: access is all-or-nothing per integration, you can't mix public and protected tools in one server. Fine-grained rules (role, ownership, plan) live inside each tool's backend logic.

How a call actually flows, and where to turn it on

User: "show me the design options under review"
 1. The assistant reads your server's manifest (the public menu of tools)
 2. It sees list_options and picks it, because the description matches
 3. Your server runs the tool, queries your data, returns the result
 4. The assistant answers in natural language

Where it lives: editor → "More" menu → Agent integrations → Enable (it runs a build, so it uses credits). Lovable reads your app's logic, proposes the tool list, and you can ask it to add, remove, rename or adjust tools. The integration runs on your live published app, not a copy: the MCP link only activates once the app is publicly published, and every publish updates the server with your latest tools. You can also keep asking Lovable to design new tools based on what your app does, who will call them, and what role that caller has.

The security check is real, and double: a basic check on every publish (warns if tools don't require authentication), plus a deep scan for public integrations that looks for private-data exposure, unintended record changes, bulk data access and paywall bypass. Findings show up under More → Security.

How people connect: your integration gets an MCP link, and users add it as a *custom connector* in their assistant. Lovable shows step-by-step instructions for ChatGPT and Claude under "How to connect", and the same link works in Claude Code, Cursor or VS Code. There's no public directory of app MCPs: people can only connect if you share the link with them.

Designing good tools (the part that separates useful from ignored)

• Name tools after what people want to do, not after database operations. submit_feedback ("use this when the user wants to say what to change or keep") beats create_feedback_record ("creates a record in the feedback table"). You're designing actions, not plumbing.
• The description IS the UX. The assistant picks a tool by reading its name and description. A vague one gets misused or ignored entirely.
• Ask for things a person can say in a sentence. Which option, keep or change, a comment saved exactly as they said it. If a tool needs a form's worth of fields, let the assistant collect them in conversation.
• One tool, one action. Three small tools (list_feedback, submit_feedback, get_request_status) beat one tool that tries to do everything (manage_feedback_and_requests).
• Never ask "who are you?" as an input. With sign-in (OAuth), every call already knows who the user is, and your app's own rules decide what that person can see or touch. If a tool takes the user's identity as a parameter, anyone can pretend to be anyone.
• Answer tidy. The assistant has to read the response and explain it. Short, well-labeled data beats a wall of text.

Use cases, grounded in the tools you'd expose

There's no fixed catalog here: you design the MCP around whatever you want to make possible. The tools can be anything your app can do, which means the right question isn't "what does this feature offer?" but "what do I want people to be able to do from their assistant?". Some starting points:

1. Personal apps. An expense tracker exposing list_expenses (read) + add_shopping_item (write): "how much did we spend on groceries this month?" and "add soap to the list" from your assistant.

2. Dev workflow. Your coding agent operates the app it's building through the front door: create_test_record, list_results. Real QA through business logic instead of raw database pokes.

3. Teams. A project hub exposing list_pending(status=open): anyone asks "what's still pending on project X?" from their own assistant, with roles intact via OAuth.

4. Client-facing products: a full tool menu. Take a design review hub where clients leave feedback on website options. A serious MCP for it is a small product surface, not two tools. These are some examples of what that menu could look like:

Five tools are enough to start: create_feedback, create_comment, list_my_feedback, get_option, summarize_round. With those, a client can hold the entire review conversation inside their assistant. And since access can gate to paying users, "AI access" can literally be a premium tier of your product.

5. Other app types.

The autonomy ladder: how much can happen without you

You don't have to build everything at once. Think of it as a ladder: each level takes a bit more work and lets the assistant do a bit more on its own. The examples here fit any app: requests, orders, reports, bookings.

• Level 0: It answers questions. Read-only tools: "what's pending?", "what's the status of my order?". Low effort, and already useful.
• Level 1: It saves complete information. Instead of a half-filled form, the assistant interviews the person ("what type of request? for when? any reference links?") and only saves when it has everything. Requests stop arriving with half the information missing.
• Level 2: It corrects before bothering you. New entries come in as drafts. If something is missing, the assistant asks the person and resubmits, so problems get fixed before your team ever sees them.
• Level 3: Your side answers back. A new request wakes up an agent of your own, which reads it and responds: creates the task, asks a clarifying question, or attaches a first draft. Next time the person asks "any news on my request?", there's an answer waiting. A full conversation loop, and nobody opened a dashboard.
• Level 4: It takes the initiative. MCP can't send notifications yet, but you can expose a "pending news" tool: the next time the person opens their assistant, it starts with "there's an update on your project, want to see it?"
• Level 5 (advanced): It becomes a co-pilot. Combine several read tools and the assistant starts connecting the dots across time: "in your last two orders you flagged slow delivery; this supplier ships express, want to try them?" It's not one question, one answer anymore: it remembers what the person said before and suggests the next step.
• Level 6 (advanced): It connects to your other systems. The loop extends beyond your app. Say each client request is linked to a ticket in your internal tracker: when your team closes the ticket, your app marks the request resolved, and the assistant can tell the client "that change already shipped, want to see it?" Your app, your tracker and the assistant close the circle with no one copy-pasting updates between systems.

Levels 0 and 1 are each about a day of work. Level 3 needs an agent running on your side. Levels 5 and 6 are the advanced end, real "wow" territory, but they only make sense once 0 to 3 are running and people actually use them. Start at 0 or 1, validate, then climb.

Limitations worth knowing before you design around them

• MCP is synchronous. Tool calls have a client-side timeout, usually tens of seconds. Don't expose heavy OCR, complex image generation, large-scale scraping, or long LLM chains directly. Expose the "start" action instead, let the heavy work run in your app, and let the user check status with another tool.
• Tool changes need a refresh. Assistants hold onto the tool list they saw when connecting: if you add, remove or rename tools, your users have to refresh the connector in their assistant to see the new version.
• No built-in rate limit or spending cap. Nothing stops a chatty assistant (or a scripted client) from hammering your tools. If a tool triggers anything that costs money or resources, put your own limits in the backend.
• It's not a general-purpose API. MCP is optimized for a language model choosing and calling tools. If you need a traditional REST API for another service, MCP isn't the right shape for that.
• Security basics: never use a service-role key in a public tool, never accept a user id as a tool input for an authenticated tool (pull it from the token), never echo the user's token back in a response.

Checklist before you publish

• Every tool has a clear title, description and input schema
• Annotations reflect whether each tool reads or writes
• Anything exposing private data uses OAuth, not public access
• RLS protects every table the tools touch
• No service-role key anywhere near the MCP code
• You tested at least three real prompts against the live server
• You wrote a short doc for users on how to connect

TL;DR: MCP is a bridge that lets assistants like Claude, ChatGPT or Cursor read and act on your app in real time. Not magic: a clear contract of tools you expose, so the AI works with your data, your flow and your users, safely and on purpose.

Docs: lovable.dev/blog/agent-integrations · docs.lovable.dev/features/agent-integrations