A client types a question into their assistant and gets an answer out of your database. In Lovable's own example, the assistant matches "do I have any requests waiting on me?" to a generated `list_open_requests` tool, calls it, and reads back live data from the published app [5]. No one opened the app, and no one wrote the integration by hand.
What the docs pitch is distribution: reach users where they already work, and give the app a new experience without rebuilding it [15]. What the owner is actually doing is publishing a machine-callable API of their app's actions, proposed by a model, gated by one question about whether callers must sign in [1]. Those are not the same task, and the second one is the one you answer for.
Look at the tool list in the docs' client portal example. Three tools, one of them marked read-only, which leaves two that create or fetch state [4][1]. Lovable's own guidance says an integration is a poor fit when the only possible tools would be slow, expensive, destructive, difficult to reverse, or unsafe to run twice, or when they would expose more data than the use case needs [7]. A `create_request` call is a form submission that no user filled in, and each call runs your app's normal backend logic, so the duplicate lands in your database and on your bill [11].
The access control is real but uneven. Your app keeps enforcing roles, plans and its other rules, which is why Lovable suggests selling assistant access as a paid tier [3]. But keeping the tools themselves private requires publishing to a workspace, and that is a Business or Enterprise option; Free and Pro workspaces have to publish publicly, so their only lever over the generated tools is the sign-in requirement [8][2]. Owners on a connected Supabase project hit a further gate: enable the OAuth 2.1 authorization server in the Supabase dashboard and reconnect, or Lovable will not build an integration that requires sign-in at all [10]. That refusal is the most useful thing in the prerequisites, because it declines to ship something that looks authenticated and is not.
So here is the sort with two axes and four cells [3]. Reads behind sign-in: the default, ship them. Reads open to anyone: you are publishing a dataset, so price and log it like one. Writes behind sign-in: only if the action is genuinely safe to run twice, because a retry is indistinguishable from intent. Writes open to anyone: no.
The forcing question for each proposed tool is whether you would document it in a public API reference under your own name and your app's rate limits. Lovable is explicit that it proposes tools but does not decide whether the integration is valuable or appropriate for your app [6]. That judgment lives in the review pass you get before you publish, and the tools you cannot defend in a support thread on Friday are the ones to delete there [3][13].
