Lovable MCP: choose the right connection direction

AppHandoff is a separate coordination product, not the official Lovable server or a backend/runtime generator. Use it when work crosses clients and the next agent needs a durable account of what was agreed, what changed, and what still needs proof. A ticket can carry a shared brief, an interface contract, and implementation evidence without requiring everyone to reuse one chat history.

That distinction matters for scope. A contract describes expected behavior; it does not implement an endpoint or prove that endpoint works. A ticket records work; it does not replace review. AppHandoff helps you carry those decisions between Lovable and another coding client. Your team still implements and validates the application, chooses its runtime, and decides when a change is ready. If all your work fits in one Lovable conversation, start there before adding a coordination tool.

Lovable documents chat connectors and custom MCP servers on all plans, subject to workspace controls. Connections are personal: teammates connect their own accounts. Chat connections supply context while building; they do not become part of the published app. A runtime API integration remains separate work.

Before connecting AppHandoff, have an AppHandoff account with access to the intended project. Know the project name or repository identifier, and start with a read request. Access to a Lovable workspace does not by itself grant access to an AppHandoff project. Decide which project the agent should use before asking it to create or change work. Keep credentials out of project prompts and shared briefs.

In Lovable, open Connectors, use the plus button, and choose MCP server. Name it AppHandoff, enter the linked AppHandoff endpoint, keep Direct connection, and use OAuth with Add & authorize. If the MCP option is disabled, check workspace controls. Follow Lovable’s custom-server instructions below for the current settings layout.

AppHandoff’s canonical endpoint uses Streamable HTTP and OAuth 2.1. No local AppHandoff server is required. After authorization, ask: ‘Using AppHandoff, bootstrap the project for our repository, then read the current brief and open tickets. Report the resolved project before making changes.’ Replace ‘our repository’ with its actual owner/name. If several projects are available, select the intended one explicitly. A successful sign-in alone does not prove you selected the right project.

Treat this as a setup procedure, not a claim that your workspace has already been tested. Confirm that the returned project and ticket details are correct before allowing a write.

AppHandoff defines nine tools: bootstrap, get, find, read_skill, ticket, plan, message, project, and decide_lifecycle_proposal. Start with bootstrap to resolve context, then get or find to read it. The remaining tools cover ticket work, planning, communication, and project operations. The lifecycle decision tool serves a signed-in human’s approval card; it is not an instruction for a model to approve its own work. Clients without that card may list eight tools.

Use the server’s current guidance and tool help for parameters and permitted actions. A tool being present is not permission to use every operation it exposes. Ask the agent to read the relevant ticket and explain its proposed change before modifying shared state. This keeps the first session useful even when you are still deciding how much work to delegate.

Suppose you are adding an account settings form in Lovable while a teammate uses Claude Code, Cursor, or Codex for the API. This is an illustrative workflow, not a customer result. Start with one shared brief: which settings may change, who may change them, and what the user should see on success or failure. Record a contract with the request fields, response shape, authorization rule, and validation errors.

Ask Lovable to read that brief before editing the form. If the existing API cannot support a requirement, ask it to describe the gap and propose a ticket. Review the proposed scope, then authorize the ticket creation. The other client reads the same ticket, implements the agreed behavior, and records the changed files and test results. This is an explicit handoff, not an assumption that connecting MCP automatically files work.

Continue the example by asking Lovable to read the updated contract and implementation evidence before finishing the form. Check one successful save, one invalid value, and one unauthorized request. Record what ran, the result, and any untested behavior. If the response shape changed, update the shared contract so the next session does not inherit the original assumption.

Keep completion tied to evidence. A proposed patch, a passing test, and a deployed change answer different questions. If deployment has not been checked, say so on the ticket. Do not infer completion solely from a merge or a closing phrase. The team should use the current ticket workflow and confirm the remaining acceptance criteria. AppHandoff preserves the handoff record; it cannot make an unperformed check true.

Troubleshoot in order, changing one layer at a time. First confirm direction and URL: Lovable’s official endpoint is for external clients controlling Lovable; the AppHandoff endpoint is for shared coordination. Use the exact linked endpoint, without adding a project identifier to its URL. If the tool list is stale, reconnect the connector and read it again.

Next check transport: configure remote Streamable HTTP rather than a local command or legacy SSE-only connection. Then check authentication: a 401 means the request was not accepted as authenticated; complete the AppHandoff OAuth flow again. Do not replace it with an unrelated service’s API key.

Finally, distinguish identity from project access. If sign-in works but the requested project cannot be read, bootstrap with its explicit name or repository identifier and verify that the authenticated account has access. If reads work but a write is refused, inspect the returned permission or guidance error before retrying. Keep tokens out of any error report.