Build an MCP Server With Lovable: Finance Tools Inside Chat…

MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.

You build an MCP server with Lovable by opening a published app, selecting Enable agent integrations under More, letting Lovable propose tools from your app's own logic, choosing whether callers must sign in, then publishing. Lovable hosts the server and gives you an MCP link your users paste into ChatGPT or Claude.

Two different features share the letters MCP in Lovable, and the search results for this topic mix them up constantly. One lets outside AI tools build your Lovable projects. The other, the one this article is about, turns the app you already shipped into something an assistant can operate on your user's behalf. They point in opposite directions, and only one of them has a plan gate that matters to a finance team.

Verified in the browser on 9 October 2026: the Lovable agent integrations documentation, the 15 July 2026 announcement post, the Lovable changelog entries for 15 July and 10 August 2026, the Lovable pricing page read logged out, the Claude custom connectors support article, and the ChatGPT developer mode help article.

Lovable documentation table comparing agent integrations, the Lovable MCP server and chat connectors

The Three Lovable MCP Features People Confuse

Lovable uses the Model Context Protocol in three places, and its own documentation is clearer about the difference than any third-party guide currently ranking. Direction is the thing to hold on to: who is calling whom.

Feature	Direction	What it actually does	Where it runs
Agent integrations	Your user's assistant calls your app	Your published app exposes named actions that ChatGPT or Claude can run	On your live published app
Lovable MCP server	An outside AI tool calls Lovable	Claude Code, Cursor or ChatGPT create, edit and manage your Lovable projects	On Lovable's own endpoint
Chat connectors	Lovable calls an outside service	The Lovable agent pulls context from a service while you are building	Inside the Lovable editor

Agent integrations are the subject here. They do not let an assistant edit your Lovable project, and the Lovable MCP server does not let your customers use your app. If you want the catalogue of everything Lovable can plug into while you build, that is covered separately in the piece on connectors for a finance stack.

There is a neat overlap worth knowing. A published app that has an agent integration also shows up as a connector inside its own Lovable workspace, under a Lovable apps section on the Connectors page. So the reporting app your team built becomes something you can query from a Lovable chat while building the next thing. Connections there are personal: each member connects it once for themselves.

What an Agent Integration Actually Does

People use software by clicking buttons and filling in forms. An assistant cannot click. It needs a list of actions it is allowed to call, with names, inputs and return values. That list is the MCP server, and Lovable generates it by reading your app.

Each tool is one action. For a client portal, Lovable might propose a read-only tool that lists open requests, one that creates a request, and one that returns a request's status. When a client asks their assistant whether anything is waiting on them, the assistant matches the question to the listing tool, calls it, and answers with live data from your app.

The integration runs against your live published app, not a copy. Enabling it adds tool code and connection endpoints to your project, and nothing changes for the people using the app in a browser. Lovable hosts the server and keeps it compatible as the protocol changes. When you change the app or its tools, you publish again and the integration follows.

Where this earns its keep in finance work

The pattern that pays is an operational app with data somebody needs to ask about repeatedly. A few that fit:

A client portal where the question is almost always some version of what is outstanding on my side. Covered as a build in the client onboarding portal walkthrough.
An investor update portal, where a general partner wants last quarter's numbers read back without opening the site. The build-versus-buy maths for that one is its own article.
An internal approvals console, where the useful tools are list what is pending and approve a named item.
A metrics dashboard, where summarise this week and flag anything unusual is a better interface than a chart for half the people who need it.

What does not fit: anything whose value is visual, anything static, and anything whose only possible tools would be slow, expensive, hard to reverse or unsafe to run twice. Lovable proposes tools, but it does not judge whether exposing them is a good idea. That part is yours.

Who Can Build One: The Plan Gates Nobody States Plainly

This is the fact most ranking pages get wrong or skip, so here it is from the documentation as it reads on 9 October 2026.

Scenario	Plans	Sign-in
App published publicly	Free, Pro, Business, Enterprise	Your choice, protected by default
App published to your workspace	Business and Enterprise only	Always required, no exception
App published to a custom audience	Business and Enterprise	Always required

The launch on 15 July 2026 supported publicly published apps only. The 10 August 2026 changelog entry extended agent integrations to workspace-published apps on Business and Enterprise, and that is the gate that decides whether this feature is usable for company data at all.

The reason is simple and worth spelling out. On Free and Pro, a published app is reachable by anyone with the link, and access cannot be restricted. Internal publish, the setting that keeps an app private to your workspace, appears on the Business card on the pricing page at $50 a month for 100 credits. If your app holds company books, client records or portfolio positions, the agent integration is a Business feature whether or not anyone says so out loud. The full plan comparison, including where Enterprise actually differs, is set out separately.

One more wrinkle on workspace apps. Connecting involves two sign-ins: the user first authenticates with their Lovable account to pass the workspace access check, then signs in to the app itself. The documentation is explicit that the app session is separate from Lovable workspace membership, so when somebody leaves, removing their Lovable access is not enough. Deactivate their account in the app too.

Publishing a workspace app whose integration still allows access without sign-in is blocked, not merely warned about. The publish dialog shows a message that MCP authentication is required, with a button that asks Lovable to add sign-in for you. An app already published that way keeps serving, but you cannot ship any change to it until the integration requires sign-in.

Sign-In, OAuth and What Tools Can and Cannot Reach

Agent integrations require sign-in by default. During the build Lovable asks who should be able to call the server, and the two answers are Protected with OAuth, which is the recommended default and what you get if you skip the question, and Public with no login, which you have to choose on purpose.

Three layers decide what actually happens, and conflating them is how people end up exposing more than they meant to:

Sign-in identifies the caller. The user sees your app's sign-in screen, then a consent screen approving the assistant's access.
Your app's own rules decide what that caller can do. A tool acts as the signed-in user, and backend rules such as each customer only seeing their own records apply to tool calls too. Generated tools are not permitted to work around them.
The tool definition decides what is exposed at all: its inputs, its action, and the fields it returns.

The sentence in the documentation that deserves to be read twice: a tool call does not go through your app's screens. Buttons you hid and pages you took out of the menu do not protect a backend action. If a rule only exists in the interface, it does not exist. That is the same lesson as row-level security, and it is why the data-safety article in this series is worth reading before you expose anything.

Access is set for the whole integration, not per tool. You cannot make three tools public and two protected. Inside a protected integration, individual actions can still apply their own role, ownership and plan checks. Switching between public and protected later is a build, not a toggle.

Lovable runs two automated checks. A basic one at every publish, which flags or blocks an integration that allows access without sign-in, and a deeper scan when you publish a public integration, which looks at what the tools expose and flags private-data exposure, unintended record changes, bulk data access and paywall bypass. Findings land in the project's Security view. Neither check replaces reading your own tool list.

Lovable documentation listing the four limitations of agent integrations

The Four Limits That Decide Whether This Works for You

Lovable publishes these, and almost no third-party guide repeats them. Read them before you promise anything to a client.

Tools run one at a time and time out

The assistant waits for a result with a time limit, and work taking more than tens of seconds can show as stuck or interrupted. Generating a PDF statement, reconciling a month of transactions or processing a large upload will not survive the round trip. The documented workaround is to make the tool respond immediately and add a second tool that checks the result, keeping the heavy work inside the app.

The integration cannot start a conversation

Your app cannot notify an assistant. Assistants act when a user asks, so watch this and alert me workflows do not work. A margin alert, a covenant breach, a failed payment: none of those can be pushed into ChatGPT or Claude by your app. If alerting matters, it stays in email, webhooks or whatever you use now.

Users must refresh after you change tools

Assistants keep a copy of your tool list. Add, remove or rename a tool and publish, and your users keep seeing the old list until they refresh the connector. Changes to behaviour behind an existing tool take effect immediately. This makes renaming tools expensive after launch, so spend the time on names before you share the link.

There is no public discovery directory

Nobody outside your workspace can browse a directory of agent integrations. Distribution is entirely yours: you share the MCP link. Inside your own workspace, published apps do appear under a Lovable apps section on the Connectors page.

What It Costs, and the Gap the 7 October Release Partly Closed

Three separate things, and people run them together:

Lovable charges no separate fee for hosting the MCP server, publishing it, or for tool calls.
Enabling or changing an agent integration starts a build, and builds use credits. How many depends on the app and the work involved. The credit mechanics are broken down in the credits article.
A tool call costs whatever the action behind it costs. Database operations, built-in backend usage, AI features and third-party services all count exactly as they would if a person used the app directly.

Now the uncomfortable part. The agent integrations documentation says there is no built-in rate limit and no spending cap on tool calls, and the FAQ confirms it: requiring sign-in stops anonymous calls and ties every call to a user, but it does not limit how often that user can call a tool. An assistant that decides to call your expensive tool in a loop will keep calling it.

The 7 October 2026 changelog narrows that gap, though not at the tool level. Workspace admins and owners on paid plans can now set usage limits and alerts: a credit threshold for the whole workspace, a project, a member, or, on Business and Enterprise, a group or an access token. When usage reaches the threshold you can take an alert or a hard block that stops building and pauses Lovable Cloud, AI features and metered connector requests in deployed apps. That is a workspace-level circuit breaker, which is not the same as a per-tool quota, but it is the difference between a surprise and a stop.

Practical reading: do not expose a paid or resource-intensive action through a tool unless your app already enforces a usage or plan limit for it, and set a workspace limit anyway.

The Other Half: What Your Users Need on Their Side

Shipping the integration is half the job. Your user has to be on a plan that can add a custom connector, and the two big assistants are not remotely symmetrical about this. Both articles were read on 9 October 2026.

Assistant	Can add a custom MCP connector	Write actions	Notes
Claude	Free, Pro, Max, Team, Enterprise	Supported	Free is capped at one custom connector; on Team only Owners and Primary Owners can add them
ChatGPT	Business, Enterprise, Edu for full MCP; Pro for read and fetch only in developer mode	Full MCP is in beta and limited to Business, Enterprise and Edu	Web only, no mobile; developer mode must be switched on in settings

That asymmetry is the single most useful thing to know before you build. If your tools only read, you can reach Claude users on every plan including Free, and ChatGPT Pro users in developer mode. The moment you add a tool that writes, your addressable ChatGPT audience collapses to Business, Enterprise and Edu, and it is a beta that OpenAI says may change.

Two smaller traps on the ChatGPT side. Published Business apps cannot be updated after publishing, so a tool change means recreating and republishing the app in ChatGPT, on top of Lovable's own requirement that users refresh the connector. And in both assistants the connector has to be enabled from the chat composer for that conversation, which is the real answer to almost every report that the assistant is ignoring the app.

Other MCP clients, including Claude Code, Cursor and VS Code, connect with the same link through their own custom-connector setup. Lovable only ships in-product connection steps for ChatGPT and Claude.

Lovable pricing page plan cards showing Internal publish on the Business plan at 50 dollars a month

A Finance Worked Example: Start Read-Only

Take an app that already exists: a small practice's client portal holding invoices and a simple holdings summary per client. Here is the tool set that is safe to ship first, and the one to hold back.

Ship these first

Tool	Type	Input	Returns
get_invoice_status	Read-only	Invoice number	Status, amount due, due date, last payment date
list_open_invoices	Read-only	None, scoped to the signed-in client	Invoice numbers, amounts, due dates
get_portfolio_summary	Read-only	None, scoped to the signed-in client	Total value, allocation by asset class, as-at date

Every one of those is scoped to the signed-in user by the app's existing backend rules, returns a small number of fields, and is harmless if the assistant calls it four times because it was not sure. Note what the returns column does not contain: no account numbers, no full transaction history, no other clients. A read-only tool still leaks whatever you let it return.

Hold these back until the first set is boring

Tool	Why it waits
create_payment	Moves money. An assistant retry creates a second payment
update_client_details	Changes records an audit trail depends on
generate_statement	Slow enough to hit the timeout, and expensive if looped
export_all_clients	Bulk access, exactly what the deep scan is built to flag

If you do ship a write tool, make it safe to repeat

This is the failure mode that costs real money and it is worth stating precisely. An assistant that times out may retry the call. If the tool creates something, it can create it twice. A duplicated payment instruction, a duplicated journal entry, a duplicated invoice: none of these are theoretical, and the assistant will not tell you it happened.

The fix is idempotency, and you can ask for it in plain language. The tool should accept a request identifier from the caller, or check whether the same change was already applied, and return the original result rather than doing the work again. A prompt that works:

Make the create payment tool idempotent. It should accept a client-supplied request id, store it, and if the same request id arrives again return the original result instead of creating a second payment. Also check that the signed-in user owns the invoice before doing anything.

Then test it the way the documentation tells you to: run each tool as an ordinary signed-in user, try protected tools as a user without the role or plan, request a record belonging to someone else, and run every write action twice to confirm nothing duplicates.

Setting It Up, Start to Finish

The whole flow is six steps, and none of them involve writing MCP code.

Open the project and go to More, then Agent integrations. You can set this up before publishing, though the MCP link only appears afterwards.
Select Enable agent integrations. This starts a build, which uses credits like any other build.
Answer the access question. Protected with OAuth unless you have a specific reason, and for a workspace-published app it is the only option.
Review the proposed tools in the AI tools section. Each shows a status, Active, Not published or Inactive, and a capability label of either Read-only or May modify data. Ask Lovable in plain language to rename, narrow or remove anything.
Publish the app, publicly or, on Business and Enterprise, to your workspace.
Copy the link from the Your MCP link card and share it with your users.

Two prerequisites catch people out. Newer apps on TanStack Start host the integration in the app itself, and for tools that are open to anyone and only return information already built into the app, no backend is needed at all. Older React and Vite apps need the built-in Cloud backend, and Lovable cannot add an agent integration to an older app that uses your own Supabase project. Check which one you have before promising a date.

One operational detail for later: on TanStack Start apps the MCP link is derived from the app's web address, so changing the primary custom domain changes the link and every user has to paste the new one. On older React and Vite apps the link points at the backend function and survives a domain change.

Should You Build One At All?

A short honest answer. Build one if your app holds data people ask repeated questions about, if those questions are answerable in a sentence, and if you are content for the first version to be read-only. Do not build one because it is new.

If the answer is yes and you are not on Business yet, the plan page is the place to check what internal publishing costs before you commit to a build.

The three conditions that make it worth the credits:

Your users already live in an assistant. If they do not, you are adding a surface nobody visits.
The app's useful actions are nameable. If you cannot write a one-line description of what a tool does and what it returns, the assistant will not pick it correctly either.
Your backend, not your interface, enforces your rules. If it does not, fix that first.

The three that mean wait:

Your app's value is visual or interactive.
Your only candidate tools are slow, expensive or destructive.
You need alerts rather than answers. The integration cannot do that, and nothing in the roadmap published so far says it will.

If you are weighing Lovable as a whole rather than this one feature, the full review covers where it holds up and where it does not.

Frequently Asked Questions

Can Lovable use MCP servers?

Yes, in two separate directions. Chat connectors let the Lovable agent use external MCP servers for context while you build, and workspace owners can add a whole MCP registry for members to pick from. Separately, agent integrations make your published Lovable app into an MCP server that outside assistants use. Workspace admins can switch remote MCP connectors off entirely in Privacy and security settings.

Can I build my own MCP server?

You can, by hand, in any language. With Lovable you do not have to: enabling agent integrations generates and hosts the server for you from your app's existing logic. If your project already contains a hand-built MCP server on the same routes, the build fails rather than overwriting your code, and you can ask Lovable to rebuild it as an agent integration or move it to another path.

Can Claude and Lovable work together?

In three ways, and they are worth keeping apart. Claude can build and manage your Lovable projects through the Lovable MCP server. Your published Lovable app can be added to Claude as a custom connector through an agent integration. And a Lovable app with an agent integration becomes usable inside Lovable's own chats. Custom connectors are available to Claude users on Free, Pro, Max, Team and Enterprise, with Free limited to one.

How do I integrate Lovable with ChatGPT?

Publish the app, enable agent integrations, copy the MCP link, and add it in ChatGPT as a custom connector under Apps. Your users need developer mode switched on, and as of 9 October 2026 full MCP with write actions is a beta limited to ChatGPT Business, Enterprise and Edu, with Pro restricted to read and fetch. It is web only.

Does Lovable have an API?

Yes, and it is a different thing again. The public Lovable API uses API keys that require a Business or Enterprise workspace and an owner or admin to create. An agent integration needs no API key: callers authenticate against your app through OAuth, not against Lovable.

Do tool calls cost extra?

Not as a Lovable fee. A tool call runs your app's normal backend logic, so whatever that action consumes is what it costs, the same as if someone clicked the button. The build that enables or updates the integration does use credits.

Where To Start

If the app you want to expose holds company or client data, the integration has to be a workspace-published app, and that puts you on the Business plan. If you are on Pro today and the app is already live publicly, you can enable a read-only integration this afternoon and see whether anyone uses it before paying for anything.

You can compare the plans and start on the Lovable pricing page. If you would rather have someone scope the tool list and the permission checks with you before anything goes live, my Lovable Expert directory profile is the place to start.

Two further pieces in this series are worth reading alongside this one: how Lovable workspaces and roles work for a finance team, and the connector catalogue if you are wiring the app into accounting or market data as well.

References

Lovable documentation, Publish your app as an MCP server, read 9 October 2026
Lovable blog, Your Lovable app now works inside ChatGPT and Claude, published 15 July 2026
Lovable changelog, entries for 15 July, 10 August and 7 October 2026
Lovable pricing, read logged out 9 October 2026
Lovable documentation, Lovable MCP server
Lovable documentation, API keys
Anthropic support, Get started with custom connectors using remote MCP, read 9 October 2026
OpenAI help centre, Developer mode, apps and full MCP connectors in ChatGPT, read 9 October 2026

About the Author

TJ Alam is a certified Lovable Expert on the Website Builder track and the founder of Digi Flock Enterprises. He has built tjalam.com and cyberdance.in with Lovable, and writes about the platform for MoneyFlock. His Lovable Expert directory listing is public.