WorkerKitFor Lovable
AI workers for Lovable.
Lovable builds apps from a conversation, and it reads your own tools through chat connectors while it works. Add a WorkerKit fleet as one of them: background AI workers, each with its own instruction, memory, schedule, budget and scoped app access, hosted around the clock. Lovable can search the catalog, run a worker and build from what it found, and every job keeps its schedule once the project tab is closed. The catalog connects with no credential, and the fleet through one approval on a WorkerKit page.
Start here
Add WorkerKit to Lovable in about a minute.
Lovable adds MCP servers on its Connectors page and no link can fill that form in, so the button opens the page and each address copies in one press. No key is pasted into a chat.
- 01
Add the catalog
On the Connectors page, press the plus button at the top right, then MCP server. Name it WorkerKit directory, paste the catalog address, choose No authentication and select Add server.
- 02
Add your fleet
Add a second MCP server named WorkerKit fleet with the fleet address and OAuth, select Add & authorize, then sign in to WorkerKit and approve. An account admin picks the key.
- 03
Ask Lovable to check it
Paste the prompt into a project chat or into Chats. Lovable shows an approval card before anything that writes.
- Catalog address, No authentication
https://mcp.workerkit.ai/directory - Fleet address, OAuth
https://mcp.workerkit.ai/workers - Paste into a Lovable chat
Use my WorkerKit fleet connector. Call key_info and tell me which account and scopes you have. List my workers and recent runs. If there are none, ask what job I want done and suggest a ready-made kit for it. Ask me before you run, install or change anything.
- Open Lovable Connectors The catalog page where custom MCP servers are added.
The setup guide covers each screen, the skill, and an optional connector that lets an app you build read your workers.
Why WorkerKit
Control your AI workforce from Lovable.
Ready-made, self-learning AI workers with only the access each job needs, a budget you set, and a record of every job and action.
- Ready-made AI workforce. Install a worker kit and a worker arrives with its instructions, app permissions and schedule already written and reviewed. Choose one from the catalog, or build your own.
- You set the budget. Workers stay inside it. Each worker has a per-run and a daily spending limit, under a limit for the whole account. When one is reached, new runs stop before any money moves, and the receipt says why.
- Only the access each job needs. Nothing more. Each worker holds its own grant for each app, read-only by default, and nothing it reads can widen it. An assistant's key carries only the scopes you choose and never an app credential.
- Self-learning, self-improving AI workers. A language worker can check every run against its job's quality criteria. A change that makes it better waits for your approval or, in Apply proven changes mode, applies on its own once it passes a comparison on your own examples. Its runs also propose what it should remember, and you approve what it keeps.
- Every job and every action, on the record. Every run leaves a receipt with its result and its cost, and every tool call is logged with its outcome, so you can see what each worker did, when, and at what price.
What Lovable is
An app builder that reads your tools.
Lovable is an AI app builder: you describe an app in its chat and it writes, runs and publishes the code. A project's chat has three modes, Build, Plan and Chat, and Chats at lovable.dev/chats are private conversations outside any project that hand work to a project when something needs building. Chat connectors bring your own tools into both, from Lovable's catalog or any remote MCP server of your own, on every plan.
| What a fleet adds | Why it helps |
|---|---|
| Work that outlives the build session | A chat connector answers while you are in the chat. A hosted worker keeps its schedule, runs at 6am and has the report waiting, whether or not a Lovable tab is open. |
| Real findings to build from | Ask Lovable for the latest run of a research or monitoring worker and build from it: a pricing page from competitor research, a changelog from a release watcher. |
| One connector, many jobs | The fleet is a single chat connector. Each worker holds its own app grants underneath it, so Lovable's connector list does not grow with the work. |
| Jobs that stay put when the build moves | The same workers answer Claude, ChatGPT, a terminal and a plain HTTPS API, so nothing is stranded in one builder. |
Two facts about chat connectors decide what WorkerKit can do there. They are personal: you connect with your own account, and a teammate connects theirs. And they never ship: a chat connection is context for Lovable while you build, never something the published app or its visitors can reach. An app that needs worker results takes a different door, a custom connector over the WorkerKit REST API, which the setup guide covers as an optional last step.
Hired specialists
What a worker adds beside Lovable.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so none of them waits on a Lovable project or a chat.
| Aspect | Lovable | A WorkerKit worker |
|---|---|---|
| Context | A project chat or a Chat, plus project and workspace knowledge | Its own, sealed per run; only the digest returns |
| Model | Lovable's own agent | Chosen per worker from any supported provider, or your own provider key |
| Identity | Your chat connections, each signed in as you | Its own, holding only the apps, tools and permissions its job needs |
| When it runs | When you send a message | Hosted around the clock: on demand, or on a schedule in its own time zone |
| What comes back | Code, a plan or an answer, in the chat | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| Memory | The project and workspace knowledge you write | The worker's own rules and facts, carried across runs, and approved by you before a run may use them |
| Taking it back | Remove the connection on the Connectors page | Disable or revoke one worker; nothing else moves |
The operator pattern
Lovable builds. Workers run.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in a project chat or in Chats. "What did the competitor monitor find this week?", "Run the review digest now", "Build a page from the latest research report." |
| 2 | Lovable | Reads its key's scopes with key_info, picks the matching tool on the WorkerKit fleet connector, and follows the operating rules in the WorkerKit skill. |
| 3 | You again, for anything that writes | Lovable runs a tool the server marks read-only without asking and shows an approval card before any other, so running, pausing or changing a worker is your click. |
| 4 | The worker | Executes in its own context, on its own runtime, on its schedule or on demand. |
| 5 | Both | Lovable reads the result with runs_feed and run_get and builds from it in the project. People who need the report get it from the worker itself, through its delivery channels. |
Lovable becomes the fleet operator while it builds: it reads the fleet, waits for your approval before anything that writes, and builds from what the workers found. The workers do the unattended work on their own schedules, and the building stays in Lovable.
Why Lovable and WorkerKit
Build in Lovable. Keep the jobs running in WorkerKit.
Use Lovable to design and ship the app. Use a worker for the job that has to run every morning against your apps, with its own grant and its own budget.
| Lovable strength | What WorkerKit adds beside it |
|---|---|
| Custom MCP servers on every plan, with OAuth, a bearer token or no authentication | Two mounts that go in by URL: the public catalog with no authentication, and the fleet through the OAuth flow its own authorization server publishes |
| Chats, a private conversation outside any project that hands work to one | A place to operate the fleet without opening a project: ask what ran overnight, then send the build to the project that needs it |
| An approval card before any tool the server has not marked read-only | A scoped key underneath every card: it holds no app credentials and reaches apps only through workers' own grants |
| Workspace skills that load when a request matches | A skill file of our own, so Lovable meets the fleet with its tool reference and operating rules already written |
| Custom connectors that let a published app call a REST API, with the credential injected server-side | The WorkerKit REST API behind one, so an app you build can show your workers' results without a key in its code |
What it unlocks
Background work that stays out of the chat.
Each run executes sealed inside its own context, settles its exact cost and returns a digest. The worker remembers its own state. Your conversation stays clean.
- Sealed jobs, small returns Every job runs in its own context and only the digest comes back. A long crawl becomes the few paragraphs that matter, so many workers fit in one conversation.
- The right model per job Inexpensive models scan, frontier models judge. Every run is priced to the token, with reserved-versus-settled tracking, so background work is never a black box on your bill.
- Money you can trust A run that never started costs nothing. A run that went silent mid-flight is absorbed by WorkerKit and labelled as an unbilled estimate. A failed run settles at actual usage with no minimum charge.
- Standing monitors and briefings Workers watch on a schedule and report only what is new, so you stop relying on remembering to ask.
- Two-way work A run that needs input does not guess or stall. It asks on every delivery channel and resumes as a linked follow-on run when you answer.
- Memory that compounds Rules and facts persist across runs, so the tenth run is smarter than the first. Anything a run proposes for memory waits for your approval before a future run may use it.
- Kits: install one or make your own Browse the catalog, install a ready-made worker, or author your own through the authoring guide, the validator and the publisher. Every path runs the same validators.
- Fleet operations Clone a tuned worker for the next client, set budgets, route deliveries, and start and stop workers, all from the assistant you already talk to.
- Delivery where people live Results land in email, Slack, Teams, Telegram, Discord, Notion, or SMS and WhatsApp, where their readers already are, instead of waiting in a chat nobody opens.
- Auditable trails Every run leaves a typed event stream, liveness heartbeats, owner and self scores, and the allow or redact outcome of each tool call underneath it.
What the two mounts expose
A public catalog, and your fleet.
WorkerKit publishes two mounts over streamable HTTP. The catalog is public, so it is never walled behind a sign-in; the fleet is yours, so it is never anonymous.
| Mount | Address | What it carries |
|---|---|---|
| Directory | https://mcp.workerkit.ai/directory | The public kits catalog: 8 read-only tools, including what WorkerKit is and when to use it, written for an agent, plus the guide, the vocabulary and the app-by-app tool explorer a kit is written from. No key at all, so the catalog can be browsed before anyone signs in. |
| Workers | https://mcp.workerkit.ai/workers | Your fleet and authoring on one connection: 122 tools in the full profile (115 manager tools plus 7 public discovery reads), or 24 tools in the decision profile. Discover sources, create classifiers, run and configure workers; the full profile also includes activity and spend, quality settings, worker access and bindings, API apps, Action workers, fleet administration, publishing and connection management. Connect through OAuth or a protected bearer header; the approved scopes control fleet operations and result access. |
| Area | Tools | What it covers |
|---|---|---|
| Continuous Learning | worker_quality_get, worker_quality_set, worker_quality_preview | Read criteria, three gates and availability reasons; save reviewed settings with expectedRevision; preview samples without a run. The worker dashboard offers owner-reviewed activation and a quoted AI draft when criteria are missing. Paid comparisons, diagnosis, monitoring, apply/rollback and company/shadow learning stay owner-only. Manager keys can disable any gate, but cannot enable automatic/shared learning. Kit install leaves all gates off. |
| Key | key_info | What your key is and exactly which scopes the other tools will honour. Call it first. |
| Fleet | workers_list, worker_get, worker_set_enabled | Every worker with live run state, one worker in full, and start or stop. |
| Apps and workers | worker_permissions_get, worker_permissions_set, worker_bindings_get, worker_bindings_set | What a worker may touch, in the same vocabulary a kit is written in, and its grants to call other workers: read both, replace its app set (account Admin) and fill, re-point or clear its worker grants. The writes need manageAppsAndWorkers; rules, identities and MCP tool bindings stay in the dashboard. |
| Runs | worker_run, run_bulk, worker_runs, run_get, run_events, run_transcript, run_cancel, run_score, run_clear_digest | Trigger a run with a prompt for that run, or one prompt across up to 20 workers; watch it step by step, read the receipt and the stored process log, cancel or grade it. On a decision worker it decides instead and acts on what it routes: sourceArgs and maxItems narrow and cap what is judged, and waitSeconds waits for the settled receipt, which carries the per-item decisions. |
| Fleet activity | runs_feed, fleet_pulse, fleet_health, account_usage, activity_feed, activity_summary, account_spend | Worker runs, app calls and configuration changes, activity counts, everything running now, fleet health, account headroom and spend by worker, day and model. |
| Two-way runs | run_question, run_answer | A run that needs an answer ends by asking; the answer starts a linked follow-on run. |
| Memory | memory_get, memory_add, memory_update, memory_delete | The rules and facts a worker carries into every run. |
| Schedules | schedules_list, schedule_create, schedule_update, schedule_delete, worker_timezone_set | When a worker starts on its own, and the time zone it works in: its local dates, its report times and the clock its daily schedules follow. |
| Instruction | instruction_get, instruction_set, instruction_versions, instruction_version_get, instruction_restore | The standing instruction, versioned on every change, with the history to compare against and roll back to. On a decision worker it reads the routing table and the install questions instead, and writes their answers. |
| Deliveries | delivery_list, delivery_channels, delivery_create, delivery_update, delivery_secret_rotate, delivery_delete | Where a run report goes when the worker finishes: email, Slack, Teams, Telegram, Notion, Discord, SMS or a signed webhook. |
| Deployment | models_list, deployments_list, deployment_get, worker_deploy, deployment_update, worker_undeploy | What makes an installed worker actually run: pick its model from the priced catalog, cap its spend, pause or resume it, take it off again. A worker with no deployment fires no schedule and refuses a run with not_deployed. |
| Budgets | budget_get, budget_set, fleet_budget_get, fleet_budget_set | A worker’s spend and run ceilings, and the account-wide fleet ceiling. Their own scope, because raising a dollar cap is the one management action that can cost money. |
| Creation | worker_clone_preview, worker_clone, worker_clone_bulk | Clone a worker into new ones, singly or in bulk, with a dry run first. A clone carries only permissions a person already approved on the source. |
| Deletion | worker_delete | Remove a worker for good, with its sub-workers. Permanent, where stopping one is not — which is why it is a scope of its own. |
| Kits | kit_install_preview, kit_install | Preview a directory kit against your account, then install it as a new worker — with deploy set, in the same call, which is what makes it run. |
| Kit authoring | kit_validate, kit_publish, kit_update, kit_replace, kit_unpublish, kit_relist, kit_make_private, kit_delete, kit_scan_get, my_kits_list, publisher_get_mine, publisher_set | Validate a kit in one dry run that reports every gate at once, publish it from content or from a worker you own, keep it private or list it, and keep your publisher profile. A private kit installed with kit_install is how an agent builds a worker from scratch. |
| Connected apps | apps_list, app_connect, app_disconnect, app_github_accounts, app_github_repos, app_github_branches, app_slack_workspaces, app_slack_conversations | Which apps an operator can use right now, in the kit vocabulary, and connecting the rest by credential: validated live, stored encrypted, never returned. Browser sign-ins stay on the Apps page. The GitHub and Slack lookups find repository and channel IDs for an install (discoverAppResources). |
| Model keys | model_keys_list, model_key_set, model_key_delete | Your own model-provider API keys, so runs bill your provider account instead of the wallet. |
| Onboarding and wallet | onboarding_get, wallet_get, wallet_checkout_create, wallet_checkout_get | Check model funding, hand off BYOK setup, inspect wallet balance, and request a human-confirmed Stripe checkout. A purchase is complete only when its status is credited. |
| Custom MCP servers | mcp_servers_list, mcp_server_get, mcp_server_create, mcp_server_discover, mcp_server_set_tools, mcp_server_delete | An app the platform does not offer, reached through its MCP server: register it as your own custom MCP app with its credential in the same call, enable the tools a job needs, and bind it in a kit. |
| API apps | api_apps_list, api_app_get, api_app_create, api_app_update, api_app_validate, api_app_preview, api_app_publish, api_app_version_get, api_app_version_revoke | Account-private API apps: validate and preview a definition offline, create and update drafts, publish immutable versions and revoke them. Authoring needs a live account Admin and managePrivateApiApps; connections and worker bindings are configured in the dashboard. |
| Decision authoring | decision_worker_create, worker_decision_set | Compile typed questions and a supported source recipe into a private kit and installed decision worker. Optional deploy; never starts a run. Requires createWorkers, plus manageDeployments when deploying. Retry the same requestId and body to recover the receipt. worker_decision_set attaches, replaces or removes a hybrid worker's classifier. |
| Action workers | action_worker_options, action_worker_create, worker_tools, worker_tool_call, worker_tool_invocation | Selected app tools with no model, called one at a time with exact inputs. Create with createWorkers; call and read receipts with invokeActions. A write needs an idempotencyKey; never resend an outcome_unknown call. |
| Support | support_request_create | Contact support about an error you cannot fix, a bug, an app request or a question. Returns a PE-XXXXXX reference. |
| Discovery and authoring reads | workerkit_about, directory_overview, kits_search, kit_get, kit_app_tools, kit_authoring_guide, kit_vocabulary | Public reads also available on the workers connection. Discover classification sources with kit_app_tools(purpose:"decision") and read kit_authoring_guide(section:"decision"). These reads never forward the manager bearer upstream. |
The manager key holds no app credentials: workers reach apps under their own grants and firewall, and no prompt can widen that. With readRuns or invokeActions the key can read what those workers return, including an Action worker's tool results.
The same two mounts answer every other MCP client, and the same fleet answers the REST API for hosts that speak plain HTTPS instead.
Classification on demand
Create a decision worker from your questions.
Categorize, score or triage connected data, then reuse and adjust the worker.
Reuse an existing worker or decision kit when its questions fit. For a custom classification task, creation compiles a supported source recipe and typed questions into a private kit and an installed decision worker. Optional deploy:true adds deployment; creation never starts a run or adds a schedule. The kit can be edited and published later through the normal kit lifecycle.
On the workers connection, call kit_app_tools(purpose:"decision") for recipes, argument schemas, permissions and examples, then kit_authoring_guide(section:"decision"). Check account connections with apps_list; public discovery does not check them. Send the request to decision_worker_create, follow nextCall, then use worker_run and run_get. Running needs runWorkers; results need readRuns. Use instruction_get / instruction_set for saved category or level answers, or answers on one run. Structural question/source changes need a revised kit and a replacement install. Check receipt status, coverage, omissions, warnings and cost before claiming completion.
Start with email-previews, calendar-events or sheets-rows. These recipes return judgments without app writes. Email previews do not include full threads; calendar events are invitation data, not transcripts; Sheets needs a Google file ID, a finite tab-qualified range and a columns map. A connected app alone does not make every tool a supported source. Source filters select evidence, not permissions: the Sheets recipe grants spreadsheet reads across the linked Drive account.
Supply 1–8 questions: choice with named options, score with ordered levels, or noul for the probability of a statement. Choice adds unclear automatically. Set an explicit confidenceFloor between 0 and 1; it routes uncertainty and does not promise accuracy. maxItems is 1–50, default 20. Creation requires createWorkers; optional deployment also needs manageDeployments.
Use a fresh requestId for each new worker. Retry with the same ID and identical body to recover the original receipt; a changed body returns 409. The response includes tokenId for MCP/CLI worker commands, stable workerId, kitSlug, readiness and nextCall. A deploymentError means the worker already exists: fix deployment on that worker. The receipt is a snapshot; check current worker readiness before running. No worker API secret is returned.
The workers connection includes discovery and authoring, so classification needs one MCP connection. Its full profile includes fleet management, app resource discovery, kit authoring and public directory reads. For a smaller list, a client that supports custom headers can send X-WorkerKit-Profile: decision on every request, including initialization, listing and calls, to select 24 workflow tools. A server operator can instead set MCP_WORKERS_PROFILE=decision. The endpoint and existing sign-in stay the same; a profile grants no additional permissions. Reconnect and relist after changing profiles. Use the advertised tool list: fleet administration, publishing, Action worker and event-stream tools require the full profile. Successful responses include structured content and a text fallback; creation declares an output schema.
App tools, no model
Call app tools through an Action worker.
One exact app operation per call, with the inputs you supply.
An Action worker (modelType: "none") exposes 1 to 64 selected app tools and has no model, instruction, schedule or deployment. Each call invokes one tool with the arguments the caller sends, under the worker's own app access, and readiness.canInvoke on worker_get says whether its tools can be called now. Run and deploy requests answer 400 action_worker_requires_invoke.
On the workers connection's full profile: action_worker_options lists apps, tool schemas and defaults (readWorkers); action_worker_create copies an app's default tools, or takes an actionSpec of 1 to 64, plus a slackConnectionId for Slack tools when the account has more than one Slack bot (createWorkers); worker_tools lists the saved tools (readWorkers); worker_tool_call calls one with arguments, plus an idempotencyKey on a write (invokeActions); worker_tool_invocation reads a write's receipt (invokeActions). Pass the returned tokenId. kits_search(modelType:"none") finds Action kits; install one with kit_install and no deploy.
A write tool (readOnly: false) needs an idempotency key. Repeating the key with the same arguments returns the stored receipt (a confirmation, not the app's response) without calling the app again; with other arguments it is a 409. A call answers with status succeeded, denied, failed, in_progress or outcome_unknown; branch on it, not on the HTTP code. On outcome_unknown the write may have happened: never resend it automatically, under any key; read the receipt and check the app. Each call counts toward the worker's daily request limit; a refusal marked retryable, such as usage_limit, is retried later under a new key. Only the owner changes the selected tools, in the dashboard.
Access and control
Scoped per worker, and scoped for Lovable too.
| Layer | What it holds |
|---|---|
| Per-worker grant | You connect each account yourself and choose what the worker may do there: per-app operations, read-only by default, narrowed by rules such as contact blocks, label and folder rules, customer-domain limits, time windows and IP allowlists. An account-level ceiling caps what any worker can be granted. |
| The app firewall | Every tool call is checked against the grant and the rules, field-masked, scanned for sensitive data, redacted, rate-limited and logged with its outcome. The worker's model never sees what the rules removed. |
| Prompt injection | A worker steered by content it reads still cannot exceed its grant. Proposed memory waits for a human. Publishing a kit to the directory runs a supply-chain and prompt-safety scan that fails closed. |
| The assistant's own access | A manager key carries explicit scopes, is shown once and stored hashed. No scope gives it app credentials, but invokeActions returns an Action worker's tool results, so grant it only where an agent should call those tools. An agent reads its scopes before planning, and an admin can revoke the key at any time without touching a worker. |
A worker is only as trustworthy as the access behind it, so the access is yours to give, to narrow and to take back, one worker at a time. You delegate without handing over the kingdom.
How it connects
Two connectors, one sign-in.
Lovable adds a remote MCP server from its Connectors page: the plus button at the top right of the catalog, then MCP server, a name, the address and an authentication method. Custom MCP servers are on every Lovable plan, and on Business and Enterprise a workspace admin can switch them off, which is the one gate worth checking first.
The catalog mount takes No authentication. The fleet mount takes OAuth, the form's default: it is an OAuth 2.1 authorization server as well as an MCP server, and lovable.dev is on the list of clients it accepts a registration from, so Lovable registers itself and sends you to a WorkerKit consent page. An account admin picks or creates the manager key the connection will hold there, and nothing is pasted into a chat.
The whole procedure, written for the agent doing it, is the setup guide. The person's part is about a minute.
Two limits are Lovable's, and the page states them rather than working around them. A chat connection belongs to the person who made it, so each teammate connects the fleet for themselves. And it is never part of the published app, so a visitor to something you built cannot reach your workers through it.
For an app that should show worker results, a workspace admin can define a custom connector over the REST API with a read-only manager key, which Lovable stores and injects on the server. The same fleet answers from any other MCP client and from the wk CLI in a terminal.
If the sign-in does not complete, Lovable's Bearer token option takes a manager key instead, and the setup guide says how to keep that key narrow.
Cost: WorkerKit has a Free plan with no card required. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the budgets you set. Connecting Lovable is not a paid feature, and the plans are on the pricing page.
Questions
Lovable and WorkerKit, answered.
- Can Lovable connect to WorkerKit over MCP? Yes. Lovable connects any remote MCP server as a chat connector, on every plan, from the plus button on its Connectors page. WorkerKit is two of them: the public catalog, which needs no authentication, and your fleet, which signs in over OAuth. Once connected, Lovable can use both in a project chat and in Chats.
- Can the app I build in Lovable use my workers? Not through the chat connector. Lovable keeps chat connections out of published apps, so no visitor reaches your workers that way. For an app that should read worker results, a workspace admin can create a custom connector over the WorkerKit REST API, holding a bearer manager key that Lovable stores and injects on its server. Give that key the read scopes only, because anyone who can use the app can trigger what the app calls.
- Do I paste a WorkerKit key into Lovable? Not on the main path. The fleet mount is an OAuth 2.1 authorization server, so you approve on a WorkerKit page and the connection holds the key. Lovable also offers a Bearer token option for servers without OAuth: use it only if the sign-in does not complete, with a key created for Lovable alone, typed into that field and never into a chat or into knowledge.
- Does Lovable ask before a worker runs? It does for anything the server has not marked read-only: an approval card appears, so running, pausing or changing a worker waits for your click. Lovable also offers Always allow all tools from this connection, which covers tools a server adds later as well. Leave that off for the fleet connector and approve each write as it comes.
- Do workers keep running when Lovable is closed? Yes. WorkerKit hosts every run, so a scheduled worker runs at its time whether or not a Lovable project or chat is open. Lovable's own documentation describes no background or scheduled work in Chats, which is the gap a worker fills: the result waits in runs_feed, and in the worker's delivery channels, for the next time you open Lovable.
- Can my whole team use the fleet from Lovable? Each person connects it for themselves. Lovable makes chat connections personal: you sign in with your own account and only you can use the connection. For the WorkerKit fleet that means each teammate approves on the consent page, and an account admin picks the key every connection holds, so one person's reach can be narrower than another's.
- What does it cost? Connecting costs nothing on either side: Lovable offers custom MCP servers on every plan, and WorkerKit's Free plan runs 5 workers with no card. Model tokens for each run are billed at the provider list price with no markup, from a prepaid wallet or your own provider key, under the budgets you set per worker. Messages to Lovable spend Lovable credits as usual.
The setup guide is written for the agent doing the work, the MCP server page holds the surface behind it, and the wk CLI reaches the same fleet from a terminal.
To build a kit of your own, how to build a kit walks the procedure, and the kit-authoring skill is the file an agent keeps for it.