Lovable MCP server (research preview)

---
name: lovable-mcp
description: >
  Use Lovable's MCP server to create, iterate on, and deploy full-stack web apps from natural-language prompts.
  Trigger this skill whenever the user wants to build a web app, dashboard, internal tool, prototype, landing page,
  or any frontend/full-stack project using Lovable — whether they say "Lovable" explicitly or just need a working
  app built and deployed fast. Also trigger when the user wants to manage Lovable projects programmatically:
  listing workspace projects, auditing edit history, reviewing diffs, reading project files, checking deployment
  status, managing databases, or setting AI governance policies. If the user mentions "Lovable," "lovable project,"
  "lovable app," or asks to build/ship/deploy a web app and Lovable is available as a connected MCP, use this skill.
  Even if they just say "make me an app" or "build a dashboard for X" — if the Lovable MCP is connected, this skill
  applies. Covers the full lifecycle: create → iterate → review → deploy.
---

# Lovable MCP Server

Build, iterate, inspect, and deploy full-stack web apps through Lovable's MCP server — without ever opening the Lovable UI.

Lovable's agent handles the heavy lifting: you describe what you want in plain language, and it builds a working app (React + Vite + Tailwind + Supabase when needed). The MCP server exposes this capability programmatically, so you can drive the entire workflow from any agent that supports skills.

## When to use this skill

- The user wants a **new web app, dashboard, prototype, or internal tool** built from a description
- The user wants to **iterate** on an existing Lovable project (add features, fix bugs, change design)
- The user needs to **inspect** a Lovable project: read source files, review diffs, trace edit history
- The user wants to **deploy** a Lovable project to production
- The user needs **workspace management**: list projects, audit activity, set governance policies
- The user wants to **provision or query a database** on Lovable Cloud

---

## Core Workflow

The typical flow is: **create → iterate → review → deploy**. Each step maps to specific tools.

### 1. Create a project

Use `create_project` with a clear, detailed prompt. The Lovable agent starts building immediately.

```
create_project(
  workspace_id: "your-workspace-id",   // required — get from list_workspaces()
  description: "Project management dashboard",  // required — short project name
  initial_message: "Build a project management dashboard with a kanban board,
  team member list, and a sidebar for filtering by status and assignee.
  Use a clean, modern design with a dark mode toggle."
)
```

Returns: `project_id`, `editor_url`, `preview_url`, `sandbox_url`.

**Full parameter list:**
- `workspace_id` (required) — target workspace
- `description` (required) — short project name, shown in the editor
- `initial_message` (optional) — the build prompt sent to the Lovable agent; omit to create a blank project
- `tech_stack` (optional, default: `vite`) — override if you need a specific stack
- `template_project_id` (optional) — clone from a template; get IDs from `list_template_projects`
- `selected_libraries` (optional) — attach workspace design system libraries; get IDs from `list_library_projects`
- `visibility` (optional) — `draft` (Restricted: creator only, requires Business or Enterprise) or `private` (Workspace: all workspace members, default)

**Prompting tips for initial_message:**
- Be specific about what the app should do, not just what it should look like. Lovable's agent is strongest when it understands the *purpose*.
- Mention the data model if you have one in mind ("each task has a title, status, assignee, and due date").
- If you want a particular tech choice, say so — otherwise Lovable picks sensible defaults (React, Vite, Tailwind, shadcn/ui).
- You can reference design inspirations: "similar layout to Linear" or "card-based like Trello."

### 2. Iterate on what's built

Use `send_message` to talk to the Lovable agent on an existing project. This is the same agent quality as the Lovable UI — treat it like a conversation with a skilled developer who can see the entire codebase.

```
send_message(project_id: "...", message: "Add a drag-and-drop feature to the kanban columns.
Also, the header font feels too heavy — switch to Inter at 500 weight.")
```

Returns: `message_id`. Use this with `get_diff` to see exactly what changed.

**Iteration best practices:**
- One conceptual change per message tends to produce cleaner results than cramming five unrelated requests together.
- If something went wrong, describe *what you see* and *what you expected* — the agent debugs well when given concrete symptoms.
- You can reference specific files: "In `src/components/KanbanBoard.tsx`, the drag handler doesn't update state correctly."

### 3. Review changes

Use `get_diff` with the `message_id` from `send_message` to inspect what the agent changed. This is your code review step.

```
get_diff(project_id: "...", message_id: "...")
```

If you want broader context:
- `list_files` → discover the project structure at any commit
- `read_file` → read the full contents of any file (requires a git ref — get `latest_commit_sha` from `get_project`)
- `list_edits` → see the full edit history with timestamps, prompts, and commit SHAs

### 4. Deploy

Use `deploy_project` to publish the current build to production.

```
deploy_project(project_id: "...")
```

Returns: the live production URL. On Free and Pro plans the app is publicly accessible immediately. On Business and Enterprise plans, access follows the project or workspace website access setting.

---

## Tool Reference

### Project Operations

| Tool | What it does | When to use it |
|---|---|---|
| `create_project` | Creates a new Lovable project from a prompt | Starting a new app, dashboard, tool, or prototype |
| `send_message` | Sends a prompt to the Lovable agent on an existing project | Iterating — adding features, fixing bugs, changing design |
| `get_project` | Returns project details (URLs, latest commit, publish status) | Before any project operation, to confirm state and get current refs |
| `list_projects` | Lists all workspace projects (supports search) | Discovery, auditing, finding a project by name |
| `deploy_project` | Publishes current build to production | Shipping the app |

### Code & History Inspection

| Tool | What it does | When to use it |
|---|---|---|
| `list_files` | Lists all files at a git ref | Discovering project structure before reading specific files |
| `read_file` | Returns full file contents at a git ref | Inspecting source code, config, or any project artifact |
| `get_diff` | Returns the diff for a specific edit (by message_id) | Reviewing what changed after a `send_message` |
| `list_edits` | Full edit history (reverse chronological) | Understanding how a project evolved, locating past changes |
| `get_message` | Status and details of a specific message/edit | Checking if a `send_message` completed, is running, or failed |

### Workspace Governance

| Tool | What it does | When to use it |
|---|---|---|
| `list_workspaces` | Lists all workspaces the user belongs to | First call if workspace_id is unknown — most tools require it |
| `get_workspace` | Workspace details: plan, credits, members, settings | Checking account state and available credits |
| `get_workspace_knowledge` | Returns AI governance policies for the workspace | Understanding what rules apply across all projects |
| `set_workspace_knowledge` | Sets AI governance policies workspace-wide | Defining standards (stack constraints, naming, security rules) |
| `get_project_knowledge` | Returns project-specific AI context | Understanding a project's defined stack and constraints |
| `set_project_knowledge` | Sets project-specific AI context | Defining tech stack, architecture decisions, or constraints for a project |

### Database (Lovable Cloud)

| Tool | What it does | When to use it |
|---|---|---|
| `get_database_status` | Checks if Lovable Cloud DB is enabled | Before any database operation |
| `enable_database` | Provisions a PostgreSQL database for the project | When the project needs persistent data storage (one-time) |
| `query_database` | Runs SQL against the project's database | Inspecting data, debugging schema, verifying migrations |
| `get_database_connection_info` | Returns credentials and connection strings | Connecting external tools (psql, pgAdmin, ORMs) to the DB |

### Analytics

| Tool | What it does | When to use it |
|---|---|---|
| `get_project_analytics` | Historical visitor metrics (pageviews, bounce rate, etc.) | Assessing how a deployed app is performing |
| `get_project_analytics_trend` | Real-time visitor count + 5-min intervals | Monitoring traffic right after a deploy |

### File Uploads

| Tool | What it does | When to use it |
|---|---|---|
| `get_file_upload_url` | Returns a signed URL for uploading a file to a project | Adding assets, data files, or binary content |

### MCP Management

| Tool | What it does | When to use it |
|---|---|---|
| `list_mcp_catalog` | Lists available MCP servers in the Lovable catalog | Discovering what external tools can be connected |
| `list_mcp_servers` | Lists MCP servers connected to a project | Checking what tools the agent currently has access to |
| `add_mcp_server` | Connects an MCP server to a project | Extending agent capabilities with external services |
| `remove_mcp_server` | Disconnects an MCP server from a project | Revoking agent access to a tool |

### Templates & Library

| Tool | What it does | When to use it |
|---|---|---|
| `list_library_projects` | Lists projects saved to the workspace library | Finding reusable templates your team has built |
| `list_template_projects` | Lists official Lovable starter templates | Finding a starting point before `create_project` |

### Authentication

| Tool | What it does | When to use it |
|---|---|---|
| `get_me` | Returns authenticated user details | Confirming auth works and retrieving user ID |

---

## Common Patterns

### Build and deploy in one flow

```
1. list_workspaces()                              → get workspace_id
2. create_project(workspace_id, description,      → get project_id
                  initial_message: "...")
3. get_project(project_id)                        → confirm it's built, get preview_url
4. send_message(project_id, "...")                → iterate if needed
5. get_diff(project_id, message_id)               → review changes
6. deploy_project(project_id)                     → ship it
```

### Audit a workspace

```
1. list_workspaces()                    → get workspace_id
2. list_projects(workspace_id)          → see all projects
3. For each project of interest:
   - list_edits(project_id)             → review edit history
   - read_file(project_id, ref, path)   → inspect code
   - get_database_status(project_id)    → check DB state
```

### Debug a stuck project

When a user has a Lovable project that isn't working right:

```
1. get_project(project_id)              → get latest commit SHA
2. list_files(project_id, ref)          → understand the structure
3. read_file(project_id, ref, path)     → read the relevant files
4. list_edits(project_id)               → understand what changed recently
5. get_diff(project_id, message_id)     → inspect the last few edits
6. send_message(project_id, "...")      → send a targeted fix based on what you found
```

### Set governance before a build

For teams that want consistent standards across projects:

```
1. list_workspaces()                    → get workspace_id
2. set_workspace_knowledge(workspace_id, "Always use TypeScript strict mode.
   All components must use shadcn/ui. No inline styles. Use Zustand for state management.")
3. create_project(workspace_id, description, initial_message: "...")  → new project inherits these rules
```

---

## Important Notes

- **`create_project` requires both `workspace_id` and `description`.** Call `list_workspaces` first if you don't have a workspace_id. The build prompt goes in `initial_message`, not `prompt`.
- **Always call `list_workspaces` first** if you don't already have a `workspace_id`. Most tools require it.
- **`read_file` needs a git ref.** Get `latest_commit_sha` from `get_project` before reading files.
- **`get_diff` uses `message_id`**, not commit SHA. Save the message_id from `send_message`.
- **`send_message` may take time.** The Lovable agent is building real code. Use `get_message` to poll status if needed.
- **One database per project.** `enable_database` is a one-time operation. It provisions PostgreSQL via Lovable Cloud.
- **Deployed app access follows your plan's website access settings.** On Free and Pro plans, anyone with the URL can visit the app. On Business and Enterprise plans, the URL may be restricted to workspace members if internal publishing is configured.
- **Credit usage.** Every `create_project` and `send_message` draws from the workspace's build credit pool. Check `get_workspace` if you're unsure about remaining credits.
- **Research Preview.** The MCP server is available to paid Lovable users only.

{
  "mcpServers": {
    "lovable": {
      "url": "https://mcp.lovable.dev",
      "headers": {
        "Lovable-API-Key": "lov_your-api-key-here"
      }
    }
  }
}