Connect Lovable
Lovable's build chat takes chat connectors: MCP servers the Lovable agent can call while it builds your app. Its prebuilt list (Notion, Linear, Jira and the like) has no regulatory source, and Lovable runs no submission process for third-party servers to join it, so you add the gateway yourself as a custom MCP server entry. The form takes a minute and works on every Lovable plan. Once connected, the agent can threat-model the app it is building from the tables, auth and connectors in the project, and read the cited article while it writes your consent flow, retention job, or access-control model.
Step 1 — add the gateway as an MCP server
Open Connectors from the Lovable dashboard (it is also reachable from inside a project), click +, and choose MCP server. Fill in the four fields:
Server name: Ansvar
Connection type: Direct connection
Server URL: https://gateway.ansvar.eu/mcp
Authentication method: OAuthKeep Direct connection. The alternative, Lovable static IPs, is an Enterprise-only option for servers behind an IP allowlist; the gateway needs none, and Lovable fixes the choice when the server is added. Click Add & authorize.
Step 2 — authorize
Lovable's default authentication method for a custom server is OAuth: after Add & authorize you are prompted to authorize. The gateway advertises OAuth 2.1 with Dynamic Client Registration, so expect a browser consent screen at auth.ansvar.eu — sign in with your Ansvar account and approve. You obtain no client ID or secret by hand. Leave the "Bearer token or API key" option alone; the gateway's interactive path is OAuth.
No Ansvar account yet? The Free plan is a self-service sign-up at the account page; the connector works on it, with the Free tool surface.
Step 3 — use it while you build
Once the connector shows as connected, the Lovable agent can call the gateway's tools during a build session. Lovable's own example for a custom server names the connector in the prompt ("Using the Internal CRM connector, ..."). Ansvar asks for the same pattern: lead with Using Ansvar so the question routes to the connector instead of the model's training data.
Try a question
Start with the app itself. Vibe-coded apps ship with no authorization model more often than with a wrong one, and a code scanner cannot see a missing one. Ask: "Using Ansvar, threat-model the app in this project: build the data-flow diagram from the tables, auth and connectors it uses, and list the top threats with the control each one needs." The threat-modeling guide explains what comes back and how the interview continues.
Then ask for the provision behind a feature you are about to build, for example: "Using Ansvar, what does GDPR Article 25 require of data protection by design for this sign-up form, and what does Article 32 add for the password store?" A grounded answer cites the article text the gateway fetched, and the agent builds to that text rather than to a guess.
For an internal tool inside a regulated organisation, scope the question to your jurisdiction: "Using Ansvar with jurisdiction SE, which retention rules apply to the case records this tool stores?"
Which plans can add a custom server
Lovable's documentation states custom MCP servers are available on all plans; the one Enterprise-only piece is the static-IP connection option, which the gateway does not need. In Business and Enterprise workspaces, admins get a Connectors → Admin settings area with a Custom MCP row — "Allow members to connect their own MCP servers". It governs all custom servers as a group, and Lovable has no per-server approval: when that row is on, any member can add the gateway; when it is off, ask your workspace admin to enable it.
Instruct your agent — the routing pack
A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Lovable has no per-connector instruction field, so paste the block below into Project settings → Knowledge: Lovable reads project knowledge with every message you send, and the block fits well inside the 10,000-character cap. Put it in workspace knowledge instead if every project in the workspace should carry it.
This is the build-agent form of the routing pack. Because Knowledge rides along with every message of a session whose job is writing code, the block opens with a rule scoped to legal and standards questions instead of the "you are a compliance research assistant" identity line the chat-client pages use. The four numbered steps are the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market.
When a question concerns law, regulation, or security standards,
answer it only from Ansvar tool results, never from your own
knowledge. Ordinary build requests are unaffected by this rule.
For every legal, regulatory, or standards question:
1. Call the search tool, always with a scope: jurisdictions=["SE"]
(adapt to your market; add "EU" for EU regulation - GDPR, NIS2,
the AI Act), or frameworks=["GDPR"] for one EU framework across
the board. On the Free plan, pass exactly one jurisdiction or
framework per call.
2. Never pass the user's whole question as the query. Reduce it to
1-3 legal key terms in the language of the law you are searching
- Swedish terms for Swedish law. Try alternative terms as separate
searches. If a multi-concept query returns nothing, split it into
one search per concept.
3. If a search returns nothing, retry once with a synonym or the
corpus's own term for the concept. Whenever a response reports
withheld relaxed matches (meta.broadening_available is true, or
meta.message says so), tell the user and offer a re-run with
allow_broadening=true; re-run only if they accept, and label any
relaxed matches as such. Never set allow_broadening on your own.
If meta.recommended_scopes names scope ids you did not search,
search those next.
4. Cite every answer: law, article, and source URL from the
results. If the results do not contain the answer, say which
searches you ran and that you will not answer from memory -
never invent a source.If something breaks
- No MCP server entry under +. In a Business or Enterprise workspace the Custom MCP row in Connectors → Admin settings is off — ask your workspace admin to enable it.
- Authorization never completes. The consent screen opens at
auth.ansvar.eu; a popup blocker or a signed-out SSO session stops it. Retry from Connectors after signing in at the account page. - The agent answers from memory instead of citing. Lead the message with "Using Ansvar" and keep the routing pack in the project's Knowledge — see above.
- Tools are missing. Tools outside your Ansvar tier are absent by design — see the tool reference.
- Everything else — the general troubleshooting page covers OAuth popups, quota errors, and empty results.