Lovable MCP Setup: Connect Lovable to Your Backend in 5 Minutes (2026 Guide)

Short answer: to set up MCP with Lovable, add https://api.apphandoff.com/api/mcp-bot as an MCP server in Lovable (or your editor — Cursor, Claude Code, ChatGPT Desktop), authorize via OAuth, and your Lovable agent immediately gets contract scanning, mismatch detection between your Lovable frontend and your backend, and shared Kanban tickets. The full Lovable MCP setup takes under five minutes — no Docker container, no local proxy, no config files, no long-lived API keys.

Lovable builds beautiful frontends fast. But the moment you need a real backend — auth, database, API routes — you're copy-pasting code between repos and hoping nothing breaks. The Model Context Protocol (MCP) fixes this by giving both sides a shared language. For a full overview of how AppHandoff integrates with Lovable via MCP, see the MCP for Lovable product page.

What Is the Lovable MCP Server?

The Lovable MCP server is a Model Context Protocol endpoint that gives Lovable's AI agent live, structured access to your project's backend context — API contracts, OpenAPI specs, mismatch tickets, design memory, and shared Kanban state — through a single OAuth-authenticated URL. Lovable supports two paths: connect from Lovable's own in-app MCP panel, or drive Lovable from an editor (Cursor, Claude Code, ChatGPT Desktop) whose MCP client points at the same server. AppHandoff hosts a public Lovable MCP server at https://api.apphandoff.com/api/mcp-bot; you don't run anything locally. Once connected, your Lovable agent can answer questions about your real backend instead of guessing from prompt context alone, which is the difference between a prototype that almost matches production and one that actually does.

What MCP Actually Does

MCP is a protocol that lets AI tools share context about your codebase. AppHandoff uses it to extract contracts from your Lovable frontend (which API endpoints it calls, what data shapes it expects) and your production backend (what endpoints exist, what they return). When those don't match, you get a ticket — not a production bug.

Under the hood, MCP contracts are versioned JSON representations of your API surface. They capture endpoint paths, HTTP methods, request parameters, response shapes, and authentication requirements. The contract is extracted automatically from code — no manual annotation needed. When your Lovable frontend calls fetch('/api/projects/:id'), the scanner records that as a contract entry with the expected response type inferred from how the result is used in your components.

Step 1: Add AppHandoff's MCP Server to Lovable

AppHandoff ships a single hosted MCP endpoint — no Docker container to run, no local proxy, no API key to paste. Open your Lovable project's MCP / integrations panel (or your editor's MCP config if you're driving Lovable from Cursor or Claude Code) and add this server:

URL:  https://api.apphandoff.com/api/mcp-bot
Auth: OAuth (click to authorize — no long-lived secrets)

If you're configuring an editor-side client, the same URL drops straight into .cursor/mcp.json, or a one-liner for Claude Code:

// .cursor/mcp.json
{
  "mcpServers": {
    "apphandoff": {
      "url": "https://api.apphandoff.com/api/mcp-bot"
    }
  }
}

// Claude Code (one-liner)
claude mcp add apphandoff https://api.apphandoff.com/api/mcp-bot

One URL, every surface. The server advertises its OAuth metadata at /.well-known/oauth-protected-resource, so any spec-compliant MCP client discovers the auth flow automatically — you don't hand-paste tokens.

Step 2: Authorize and Pick a Project

On first connect, AppHandoff bounces you through a Supabase-backed OAuth flow. Sign in, approve the app, and the MCP transport upgrades to authenticated. With exactly one accessible project, the server auto-binds project_id for the rest of the session — your agent can start asking questions immediately. With multiple projects, the agent calls get_accessible_projects once and you pick.

Every MCP response carries an X-Token-Expires-In header so well-behaved clients refresh proactively. Production JWT lifetime is 8 hours; Cursor and Claude Code refresh on their own, and you should not have to think about tokens after the first sign-in.

How Do I Confirm My MCP Connection Works? (Step 3)

Ask your Lovable agent something only AppHandoff can answer. The fastest one-liner: “Summarise this project and list my open AppHandoff tickets.” A working connection answers in a single round-trip via batch_tools, which is the bootstrap pattern we recommend for every new session — the same one our own agents use against our own shared Kanban board:

// What the agent sends under the hood:
{
  "name": "batch_tools",
  "arguments": {
    "calls": [
      { "name": "get_project_summary",  "arguments": { "project_id": "<id>" } },
      { "name": "get_design_memory",    "arguments": { "project_id": "<id>" } },
      { "name": "get_handoff_requests", "arguments": { "project_id": "<id>", "status": "open" } }
    ]
  }
}

You should see a real project name, the current design memory snapshot, and any open handoff tickets — not a stub or a 'tool not found' error. If the tool list comes back empty, see Troubleshooting below: 9 times out of 10 it's a stale tool catalogue (disconnect + reconnect fixes it) or a URL typo. The canonical URL is https://api.apphandoff.com/api/mcp-bot — /mcp alone or /api/mcp both 404.

From here, the Lovable agent has the same context an AppHandoff backend agent has: live API contracts, mismatch tickets, scan results, and the shared Kanban board. The contract scan and mismatch detection described in the next section run automatically the first time you connect a project — you don't trigger it manually.

Why This Beats Manual Handoffs

The old way: export from Lovable, manually audit the code, figure out what the backend needs, write it from scratch, test by hand, repeat every time the prototype changes. The MCP way: connect once, get continuous sync. Every push to your Lovable repo triggers a fresh scan. Drift is caught automatically.

Teams using AppHandoff's MCP integration report spending 80% less time on handoff coordination and catching mismatches before they hit production instead of after.

Troubleshooting Common MCP Issues

Tool list is empty or 'tool not found' on every call. The MCP transport connected but the client cached a stale tool catalogue. Disconnect and reconnect the AppHandoff MCP server (Cursor: command palette → MCP → reconnect; Claude Code: /mcp → reconnect). Then confirm the URL is exactly https://api.apphandoff.com/api/mcp-bot — a trailing slash, a typo'd /mcp, or http:// instead of https:// all 404 silently.

401 on every tool call after 20–60 minutes. Your Supabase access JWT expired and the client did not refresh. Production token lifetime is 8 hours, but older or non-spec-compliant clients miss the refresh window. Fastest fix: disconnect + reconnect to re-run OAuth. If you're building your own client, watch the X-Token-Expires-In response header and call POST /api/oauth/token with grant_type: refresh_token before TTL drops under 300 seconds.

'MCP error -32000: Connection closed.' The transport dropped mid-request, usually because a heavy call exceeded the 25-second timeout — a fresh trigger_rescan on a large repo, or an unfiltered get_project_summary. Retry first. If it persists, narrow the call with include: "minimal", or filter get_handoff_requests by stage / status / changed_since.

# MCP-specific failure modes and fixes:

'Tool ... was not found'        → Disconnect + reconnect MCP, check URL exact match
'401 AUTH_REQUIRED'             → OAuth flow incomplete; reconnect to re-auth
'401 TOKEN_EXPIRED'             → Refresh JWT via /api/oauth/token, or reconnect
'-32000 Connection closed'      → Request > 25s timeout; narrow with filters
'404 SESSION_EXPIRED'           → MCP transport gone (deploy / idle); reconnect
'No accessible projects'        → Create project at apphandoff.com, then reconnect
'OpenAPI not detected'          → Set backend_repo + config.openApiPath in project

Initial scan returns zero mismatches. Either the Lovable frontend still uses mock data (no real fetch calls to detect yet) or your backend has no OpenAPI spec for AppHandoff to diff against. Point AppHandoff at your backend via backend_repo: owner/repo in project settings; for monorepos, set config.appSubDir; for custom spec locations, set config.openApiPath. Next.js API routes are scanned directly when no OpenAPI is present, but coverage is better with one.

Stale results after a backend deploy. AppHandoff caches scan output for performance. Ask the agent to call trigger_rescan(project_id) — 1-2 seconds — to refresh contracts, OpenAPI parsing, and mismatch detection in one shot. The shared Kanban updates immediately.

Next Steps

Once your repos are connected and the initial scan is clean, explore the MCP server documentation for advanced features: custom contract annotations, webhook-triggered scans, and multi-project workspaces. If you're evaluating AppHandoff against other tools, the comparison page breaks down feature differences with Vercel v0, Bolt, and manual handoff workflows.

The MCP integration works best when both repos are actively developed. The more frequently your Lovable prototype and backend change, the more value continuous scanning provides. For teams shipping multiple times per day, the mismatch scanner becomes an essential part of the CI pipeline — see the Lovable-to-production pipeline for the full continuous-sync architecture, catching integration issues before they reach staging, let alone production.

About the Author

Ralph Duin is the founder of AppHandoff and the engineer behind its MCP server. Before AppHandoff he spent a decade building production systems where the design-to-code handoff was the single most expensive failure mode — eventually deciding the only honest fix was to delete the handoff entirely. He writes about AI-built software, Lovable, and engineering velocity at InspiredByFrustration.com, where he also offers one-on-one consulting for teams wiring Lovable prototypes into production backends.