Staticbot

Create a new project directly inside the customer's selected Supabase organization. This changes an external account, consumes a project slot, and may affect the customer's Supabase billing. Before calling, use list_supabase_organizations and list_supabase_regions, present the exact project name, organization, and region, and obtain the user's explicit confirmation. Staticbot generates and encrypts the database password; it is intentionally never returned through MCP. Provisioning is asynchronous: after creation, call get_supabase_project_status with the returned id until healthy=true. Do not …

Create a new template by scanning a source repository (GitHub or GitLab). Auto-detects platforms, env vars, and builders. Both public and private repositories are supported through the organization's connected Staticbot source-control integration. Before asking the user for a URL, call list_source_repositories and use an unambiguous repository match from the current client/project context, passing that repository's integrationInstanceId as sourceControlIntegrationInstanceId — with several accounts connected, only that one's token can read the repo, and omitting it makes a private repository lo…

Clear the repository's webhook configuration and request upstream deletion; pushes stop triggering its Staticbot automation. First inspect get_connected_project_operations and show every affected project and the template count sharing the repository webhook. Obtain explicit approval for that scope before confirmed=true. Copy webhook.repositoryConfigId to expectedRepositoryConfigId; do not invent it. On changed-target 409 inspect and ask again. This supports GitHub only, and agency client projects must use the source project's webhook. Secrets remain server-side. Reset and disable use best-effo…

Dismiss an OPTIONAL platform update when the user asks to decline it. Required updates cannot be dismissed.

Fetch the downloadable migration package for a migration. Returns a presigned URL to the AES-256-encrypted zip plus the password to extract it. Availability: • SUPABASE_SELF_HOSTED: this is the delivery mechanism. The user unzips with the password, runs Claude Code against the folder, and follows the bundled CLAUDE.md to apply the migration to their self-hosted Supabase. • SUPABASE_CLOUD: this is a portable backup of the applied migration (re-applicable to any Supabase later). The package is ready once the GENERATE_PACKAGE job is COMPLETED — check via get_migration_jobs first. Calling be…

START HERE for deployment, migration and sync. For a public website check, scan_website can run directly before any integrations are connected. This account check answers in one request who the credential belongs to, which integrations are connected, what the plan allows, and what is actually outstanding — so you never propose work whose prerequisites are missing. Read `pendingAction` and follow it, exactly as you would follow a migration's pendingAction: • CONNECT_SOURCE_CONTROL / CONNECT_DATABASE — deployment/migration prerequisites are missing. Give the user the `url` and stop; do not pro…

Which secrets (API keys for third-party services — Stripe, OpenAI, AWS and the like) a migrated app uses, which already have a value, what the app uses each for, and where a saved value is applied — names and states only, never a value. Pass connectedProjectId for a project (the app after go-live), migrationId for a migration, or stackId for a stack that deploys a migrated app (its preview, or a hosted version, including ones Continuous Sync minted). A project's answer is per ENVIRONMENT — what its deployments run against (the Supabase project and its values). An environment is not a pipeline …

Check whether Automatic Updates are available for a deployment and inspect its GitHub webhook state. Returns fields including `available`, `webhookConfigured`, `canSetupWebhook`, and `isGithubRepo`. Automatic Updates do not apply to preview stacks.

Get the automatic-update flags for a deployment. `autoDeployLatestWebsite` controls whether a new website template version is deployed automatically; `autoDeployLatestInfra` is reserved for infrastructure updates.

Inspect a destructive target cleanup BEFORE asking the user to authorize it. Always call this immediately before presenting cleanup, and never rely on the targetConflictReport from an earlier get_migration: that is a snapshot taken at discovery, while this is the current state of the target. Returns `available` (cleanup is only possible before execution starts, and only for Supabase Cloud targets) with `unavailableReason` when it is not, the exact `confirmationProjectRef` the user must approve, `countsAvailable` plus live per-scope `rows` describing what each of DATABASE, STORAGE and PROJECT w…

Get details of a connected project including sync mode, webhook status, linked migration, and deployment.

Inspect a connected project's current builder/live branch targets, effective permissions, and repository webhook scope, including other projects/templates sharing that webhook. Read this before proposing a preview build, live-branch switch, sync-to-live or webhook change. Permission flags are role permissions; feature flags and current workflow state can still block an action. Reading does not fetch Git or change a repository, webhook or deployment. Contains no webhook secret.

Get the status of a deployment and the per-domain DNS state. Poll this for progress. Statuses: CREATED → PENDING → IN_PROGRESS → WAITING → COMPLETED (or FAILED). **Response fields you should always read:** - `status` — pipeline state. - `dns` — per-domain DNS state, populated once Terraform emits a state snapshot. Present regardless of `status`; check it on every poll, not just on WAITING. - `requiredAction` — legacy; only set when `status=WAITING` and there are records to add. Prefer `dns`. **For each entry in `dns`, read `action` and behave as follows:** - `NO_ACTION` — registrar NS alread…

Get detailed migration state and next-action context. Use get_migration_overview for routine status polling; this detailed tool remains available whenever the full context is needed. Get the current status and phase breakdown of a migration. The response includes all migration phases (Discovery, DB Migration, Data Import, Edge Functions, Storage Buckets, Auth Config, Backend Switchover, Preview & Verify, Continuous Sync, Download, Follow-ups) with their individual statuses, plus sourceType (LOVABLE_SUPABASE / BOLT_SUPABASE / FIREBASE / BASE44_SUPABASE / BASE44_NATIVE), targetType (SUPABASE_CLO…

List all AWS deployments associated with a migration's infrastructure stack. Migrations that deploy to AWS (self-hosted Supabase) create deployments for the infrastructure provisioning.

Read the migration's discovery report and its revisionId. Present source coverage (including unknown or partial areas), findings, proposed work and approvalBlockers before asking the user to approve initial execution. Reading may retain a proposal but never starts migration or records approval. Send the exact reviewed revisionId as approvedRevisionId to confirm_migration only after explicit approval. A stale-plan 409 needs a fresh report and a new approval; never approve a changed revision automatically. Inspect sourceInspection.supported/available/inProgress/reason: optional inspect_migration…

Read a retained, sanitized discovery report by revisionId, including its recorded approval. Historical reports are read-only evidence, not a current approval candidate: use get_migration_discovery_report to review the current plan before confirm_migration. Missing historical reports return an error and must not be reconstructed or replaced silently. Reading never refreshes the source or changes execution.

Read retained, sanitized migration execution revisions. A discovery proposal or legacy baseline is not proof of approval; get_migration_discovery_report identifies the approved report. Opaque code, SQL and credentials are withheld. Reading never starts work or activates a replacement plan.

Read the sanitized Markdown handoff report: source inventory, gaps, manual actions, AI remediation prompts, names-only secret checklist, current execution/job-attempt evidence, preview and generated cron activation SQL when available. Optional revisionId selects retained discovery evidence; execution evidence still describes current execution, not a historical execution snapshot. Share this concrete checklist with the customer. Reading does not approve, retry, deploy or activate anything. Migrated schedules are staged inactive. At cutover the customer reviews and runs the exact guarded activat…

Read retained, sanitized job attempts and amendments, newest payload versions first, including deleted queue jobs. Use the oldest returned payloadVersion as the exclusive beforeVersion cursor for another page. Missing historical evidence remains unknown; credentials and opaque SQL/code bodies are withheld. Reading never retries or repairs work.

Get all jobs for a migration. Jobs are the individual work units within each phase (e.g. 'migrate_schema', 'import_data', 'deploy_edge_function_X'). Use this to understand what's happening at a granular level, diagnose failures, or find a jobId for retry/skip. For IN_PROGRESS long-running jobs (e.g. CALL_EXPORT_TO_TARGET on multi-table sources), each job's `progressMessage` field carries a human-readable subtitle like "Exporting table 'startups' (8/10)" so you can report concrete progress without waiting for completion. Each job also carries `skipGuard`: null means it is freely skippable, non-…

Read the latest retained comparison of a migration's deployed live commit with its configured repository and branch. Report verdict, needsAttention, checkedAt and message. UNKNOWN or null means missing evidence, never a successful match. Reading does not perform a fresh Git probe or modify a branch; do not present retained evidence as a new live verification.

Read the migration's stored live-site scan. A null result means no live URL has been checked. For QUEUED/RUNNING wait pollAfterMs and read again; failures are terminal. This reads the migration-linked scan rather than a standalone website check. Returns the customer summary without raw scripts, extracted credentials or contact history. Does not start target migration writes.

Read a lightweight migration overview. Prefer this for routine status polling; respect pollAfterMs (0 means stop) and compare version to detect overview changes. Returns phase/job counts, a bounded list of jobs needing attention, saved discovery report metadata/blockers, executionCompatibility, and independent preview status. No inventory, SQL, job inputs/outputs or history is loaded. No source probe, report capture, approval or writes occur. The saved report summary is not a current approval candidate. Before acting or explaining a waiting choice, read get_migration and, as appropriate, get_m…

Read the backend's deterministic migration preview evidence: what worked, what failed and what remains unverified, from deployment, HTTP checks, browser rendering and restore audits. Call before claiming a migrated preview works. Preserve unverified findings as unknown, never as passes. Reading does not create a preview, start a scan, approve or resume work. Available even when migration execution is locked.

Get details of a stack including its templates and config overrides. Every override key is listed; values are returned for location-shaped keys (URLs, regions, names, branches) and "[REDACTED]" for credential-shaped ones.

Read the lifecycle state of a Supabase project created or selected through Staticbot. After create_supabase_project, poll this tool until healthy=true before using the project as a migration target. A transitioning state means wait; it is not permission to create another project. Stop and report the returned state if unavailable=true.

Get details of a specific sync run including status, source and target repository versions, summary of changes, and error information. Use the returned version fields when explaining or reviewing the diff; do not infer them. Statuses: PENDING → IN_PROGRESS → COMPLETED/FAILED. Destructive migrations cause PAUSED_FOR_REVIEW.

Get all jobs for a sync run. Jobs are the individual work units (e.g. apply_migration, deploy_edge_function, frontend_deploy). Use this to diagnose sync failures at the job level.

List SQL migrations that continuous sync was asked to apply to this project's live database and never applied — a run failed and was never retried, or the work was skipped — where the diff window has since moved past them, so no future sync will re-offer them. Each entry means the file exists in the repo and is missing from the database. An empty list is the healthy case. Report these to the user; do NOT try to re-apply them automatically — replaying months-old DDL against a live database is the user's decision.

Get details of a template including its backend-classified configuration variables. Each entry has `key`, `configured` (whether a value is set at all), and sanitized `value`. Staticbot never returns credential values, so read `configured` to tell "withheld" apart from "not set". For migrations, follow `migrationAction`, `collectionStage`, `sensitivity`, `resolution`, `integration`, and `migrationHint`; do not infer meaning or safety from prefixes. Include a configOverride only when `migrationEditable=true`. `migrationBackendDerived=true` means Staticbot derives the value from target state and …

Read a website scan belonging to the current Staticbot workspace. Use the exact scan.id returned by scan_website. Poll QUEUED/RUNNING scans using pollAfterMs; COMPLETED, FAILED and REJECTED are terminal. Explain detection limits and failures without inventing results. Returns the customer summary without raw scripts, extracted credentials or contact history. Does not fetch the target website again or start any migration or deployment.

Queue deeper source inspection before discovery-plan approval or execution. First read get_migration_discovery_report and get_migration: stop if executionCompatibility.locked is true. Offer inspection only when sourceInspection.supported and sourceInspection.available are true; if inProgress, poll instead of duplicating it, otherwise explain reason. This commits the source helper to the source repository and deploys it to the source account, or asks the customer to sync it manually. Obtain explicit authorization for those source changes and send authorizeHelperDeployment=true; reading a report…

Use this when an existing stack's deploymentTarget is AWS_STATIC and you need to choose which AWS account will own its next deployment. Call it with that stack's stackId before create_deployment because managed-account eligibility and the current selection are stack-specific. Render the response; do not derive or repair it: - `managed` is the Staticbot-hosted option. It can be null; when null, do not offer it. - `customerOptions` contains ready-to-render `label`s and opaque `value`s for connected customer accounts. - `notices` explains why an option is absent or unusable. Surface every notice…

List the Base44 apps a connected Base44 integration can migrate. Call this before create_migration for any BASE44_NATIVE migration: a Base44 personal access token is scoped to a WORKSPACE and reaches every app in it, so the integration alone does not identify which app to migrate. Pass the chosen app's `id` as create_migration's `base44AppId`. Ask the user which app when more than one is returned — never guess, and never assume the first or the most recently edited one is meant. Migrating the wrong app is not cheaply reversible. An empty list means the token cannot see any apps: usually a toke…

List the Cloudflare accounts this app can be hosted in: Staticbot's managed account (the default) plus any Cloudflare account the user has connected. Call this before create_stack or create_deployment for a Cloudflare Workers / SSR app whenever the user has a connected Cloudflare account and might want the Worker deployed into it rather than hosted by Staticbot. Read the response, do not compute from it: - `managed` is the Staticbot-hosted option. It is always present and always valid. - `customerOptions` lists the user's own accounts — each with a ready-to-render `label` and the `value` you …

List every tracked branch preview for a connected project, including the preview deployment ID, raw deployment status, preview URL, and dashboard status URL. Always use deploymentStatus to distinguish builds in progress from FAILED, ABORTED, or COMPLETED previews; hasPreview only means preview resources exist.

List all connected projects. Connected projects sync changes from a GitHub repo to a target Supabase instance and optional Staticbot deployment. After a migration completes, enable continuous sync to keep the target up-to-date with Lovable, Bolt, Base44, or Firebase changes.

List all deployments. Optionally filter by stackId. Each deployment represents one execution of a stack's infrastructure.

Deprecated — use list_source_repositories, which serves GitHub and GitLab through one tool. Lists the public and private GitHub repositories accessible through a connected Staticbot GitHub integration: call list_integration_instances first, then pass the selected GitHub instance ID here. Returns a flat array whose repository URL field is `htmlUrl`. Never claim that Staticbot requires a public repository.

List all connected integrations for the organization. Each instance has a 'type' field identifying whether it is 'supabase', 'github', 'base44', etc. Use the instance with type='supabase' as supabaseIntegrationInstanceId, type='github' as githubIntegrationInstanceId, and type='base44' as sourceIntegrationInstanceId (for BASE44_NATIVE migrations) when calling create_migration. To resolve a repository, call list_source_repositories instead — it covers every connected source-control account in one call and reports which account each repository is hosted in. Use this tool for the supabase/base44 i…

List retained discovery report revisions, newest first, with revisionId, revisionNumber, approval time and active status. Use the oldest returned revisionNumber as the exclusive beforeRevision cursor for another page. Reading never queries the source, approves or starts work. Legacy reports that were not retained remain unknown; do not fabricate them.

List all migrations. Optionally filter by status. Migrations orchestrate moving a full project (database, auth, storage, edge functions) from a source platform (Lovable, Bolt, Firebase, Base44) to target Supabase infrastructure.

List the workspace's open pending actions, newest first: for example a required platform update waiting for approval, or a pull request Staticbot opened that needs merging. Tell the user about actionable items; never apply a platform update without their confirmation.

List a connected project's post-migration platform updates: what each fixes, its policy (AUTOMATIC, GATED, OPTIONAL), the versions it affects, what its last check found, what applying does (whatApplyingDoes), and which branches run on the migrated backend.

List the recent commit-pinned website template versions that are valid rollback targets for a deployment, newest first. Use only a returned `templateId` with rollback_website; do not infer a target from a commit SHA or version label.

List all public and private repositories accessible through the organization's connected Staticbot source-control integrations — GitHub and GitLab. Call this whenever a workflow needs a repository, with NO arguments: it covers every connected account in one call. An organization can connect several accounts on the same provider, and passing one instance ID narrows the listing to that account, which hides the others' repositories — only do that when the user has already chosen an account. The response is { sources[], repositories[] }. Each repository has `fullName`, `webUrl`, `private`, `descri…

List newer versions of a stack's infrastructure templates (for example a Staticbot-published update to the built-in AWS static-website infrastructure). Empty when the stack already uses the newest version of each. Each entry carries the current `templateId` to pass to adopt_stack_template_update, the current and latest versions, and a `message` to relay to the user.

List all infrastructure stacks. A stack groups one or more templates with a domain assignment. Each stack can have multiple deployments.

List the Supabase organizations accessible through a connected Supabase integration instance. Call this before create_supabase_project and present the organization names to the user. Use the selected organization's id unchanged as organizationId. Do not guess an organization when more than one is available.

List all Supabase projects accessible through a connected Supabase integration instance. Returns project name, reference ID, region, and status. Use the project's id field as targetSupabaseProjectRef when creating a migration. Only ACTIVE_HEALTHY projects can be used as targets. Present the list and let the user choose an existing target, or offer to create a customer-owned project with create_supabase_project.

List the regions Staticbot supports when creating a customer-owned Supabase project. Call this before create_supabase_project and use the user's selected region id unchanged. When the user has not expressed a location preference, explain the available choices rather than silently choosing one.

List sync run history for a connected project. Each sync run represents one execution of the sync pipeline — applying migrations, deploying edge functions, and rebuilding the frontend.

List available templates (slim response: id, name, category, repoLink). Use get_template to see full details including config variables. Templates feed both hosting and migration. Reuse an exact repository match when one exists; otherwise create a new template from the repository resolved through list_source_repositories. Ask the user to choose only when multiple existing templates or repositories are plausible — and when two repositories share a name, show which account each is hosted in (sourceLabel) so the choice is meaningful.

Pause a running migration. The current in-progress job will finish, but no new jobs will be started. Use resume_migration to continue later.

Check that a hosting choice and hostname can actually be deployed, before create_stack or create_deployment. Read-only: it never creates, deletes or takes over anything. It answers for the managed choice too, so call it the same way whichever option the user picked. **How to use the result:** - `ok: true` — deployable. Report `connectionLabel`, and `hostname` / `workerName` when present. `note` may add useful context (for example that an apex hostname is supported). - `ok: false` — **do not create anything.** Show the user `blockingMessage` verbatim; it names the exact collision and what to f…

Push a deployment's certificate-validation and website-routing DNS records into the customer's linked Cloudflare zone. This is an external DNS write, although it is idempotent and never changes nameservers or mail records. First call get_deployment and select the exact dns item whose action is OFFER_CLOUDFLARE_PUSH; pass the deployment response's id as deploymentId and that DNS item's domainId as domainId. Present the intended action and obtain the user's authorization before calling. Do not infer a domain ID, use this for MANUAL_RECORDS_AT_REGISTRAR, or describe it as DNS delegation. Present …

Ask Cloudflare to retry custom-hostname domain-control validation for a Cloudflare Workers deployment, then return refreshed certificate and hostname-routing status. Call this after DNS records were published or when the user explicitly asks to recheck verification. This action does not write DNS records or change nameservers. A null result means the deployment has no applicable Cloudflare custom hostname. Surface verificationErrors and do not report the domain live unless both customHostnameStatus and hostnameStatus are active.

Run a pre-flight gate's re-check action: the enabled action in get_migration.preFlightGate.actions whose ID is RECHECK_EXPORT, RECHECK_OFFICIAL_EXPORT, RECHECK_CAPACITY or RECHECK_TARGET_EMPTY. These never go to confirm_migration, which refuses them. A re-check only queues a fresh measurement: it does not confirm or start the migration, and the migration stays paused. Each assumes the user fixed something outside Staticbot first, so ask them to do that and confirm it is done before calling: RECHECK_EXPORT / RECHECK_OFFICIAL_EXPORT — they created a Cloud Data export in their Lovable project (St…

Rebuild and redeploy the static website component. By default it redeploys the currently pinned template version; set `useLatest=true` to pull the latest version first. Returns the worker job ID; poll get_deployment to track progress.

Replace the repository's GitHub webhook and rotate its internal secret; this affects push-triggered automation. First inspect get_connected_project_operations and show every affected project and the template count sharing the repository webhook. Obtain explicit approval for that scope before confirmed=true. Copy webhook.repositoryConfigId to expectedRepositoryConfigId; do not invent it. On changed-target 409 inspect and ask again. This supports GitHub only, and agency client projects must use the source project's webhook. Secrets remain server-side. Reset and disable use best-effort upstream d…

Resolve a MANUAL_REVIEW_SCHEMA_GAP gate: the source database has objects the repository's migration files don't declare. The gate's inputData.summary.builder_chat_prompt (get_migration_jobs) is the prompt the user pastes into their AI builder so it adds them. IMPORTANT: You MUST present these options to the user and ask them to choose before calling: 1. 'reprepare' — once the builder has pushed the missing migration files: Staticbot re-reads the source branch at its newest commit, re-runs discovery and rebuilds the plan. This replaces the approved plan, so the migration returns to CONFIRM an…

Resume a migration that is PAUSED_BY_USER or PAUSED_FOR_USER_ACTION. Use this after the user has completed the required manual step (e.g. DNS configuration, backend switchover review).

Retry a failed migration job, or a skipped one whose `retryableAfterSkip` is true. It will be reset to READY and picked up by the worker again. A skipped SQL file can be retried while the migration is paused: it runs first, and whatever step is failing then runs again after it; retry one skipped file at a time. Use get_migration_jobs first to find the job's ID, error message and retryableAfterSkip.

Retry a connected-project sync run in FAILED status. Resets its failed jobs to PENDING and reopens the run. Use get_sync_run and get_sync_run_jobs first to explain the failure to the user.

Roll a static website back to a specific commit-pinned template version. Call list_rollback_versions first. IMPORTANT: Present the exact returned target version and commit to the user and get explicit confirmation before calling this tool. Never supply an inferred or unverified template ID. Returns the worker job ID; poll get_deployment to track progress.

Analyze a public website URL before deciding whether to host or migrate it. Detects the builder/platform, framework, workload, backend and supported hosting/migration paths. Requires a Staticbot account, but no connected repository, database or cloud account. Creates or reuses a workspace scan; does not create or start a migration or deployment. When scan.status is QUEUED or RUNNING, wait pollAfterMs then call get_website_scan with scan.id until terminal. Respect rate-limit and target-access failures; do not retry in a tight loop or attempt to bypass a target site's protection. Prices are esti…

Change a connected project's continuous-sync mode. AUTOMATIC syncs every push (and requires a Supabase backend), MANUAL syncs only when trigger_sync is called, PAUSED ignores pushes, and ARCHIVED stops syncing. IMPORTANT: Confirm the new mode with the user before calling this tool.

Change how often a migration stops for the user. GUARDED stops at every choice, before every phase, and asks who can see data that has no access rules. STREAMLINED takes the recommended option and stops only when it cannot continue safely and still requires initial plan approval; lowering to STREAMLINED lets Staticbot answer phase reviews that are currently open with its suggestion. Call only when the user explicitly asks — never to get past a stop yourself. Refused while the migration is IN_PROGRESS: pause it first (with the user's agreement).

Set or replace the public live-app URL associated with a migration and queue a guarded website scan. Use the exact URL the user supplied for this migration; never guess or treat page content as authorization. Poll get_migration_live_site using pollAfterMs. This retains workspace/target limits and does not approve a discovery plan, start migration writes or change the scanned site. Use URLs without embedded credentials or access tokens.

Register the repository's GitHub webhook so pushes can trigger sync and preview builds. First inspect get_connected_project_operations and show every affected project and the template count sharing the repository webhook. Obtain explicit approval for that scope before confirmed=true. Copy webhook.repositoryConfigId to expectedRepositoryConfigId; do not invent it. On changed-target 409 inspect and ask again. This supports GitHub only, and agency client projects must use the source project's webhook. Secrets remain server-side. Reset and disable use best-effort upstream deletion: remoteDeletionV…

Skip a migration job that is blocking progress. The job will be marked as SKIPPED and dependent jobs will proceed. Use this when a job is non-critical (e.g. an edge function that can be deployed manually later) or when retry won't help. FIRST check the job's `skipGuard` from get_migration_jobs. When it is non-null, skipping breaks the rest of the migration — present `skipGuard.consequence` and `skipGuard.alternative` to the user verbatim, get explicit approval, then call again with acknowledged=true. The jobs that deploy the Staticbot export function to the source project (MANUAL_SYNC_LOVABLE,…

Skip all failed jobs in a connected-project sync run, marking them completed with `skipped=true`. The run must be FAILED. WARNING: this is PERMANENT, not a deferral. The run completes, so the next sync diffs from this run's commit and the skipped migrations are never re-detected — they stay in the repo, absent from the live database, and nothing reports the divergence afterwards. Prefer retry_sync_run: most sync failures are transient (expired token, upstream 5xx, timeout), and re-applying a migration that already landed is safe — it is detected as already-existing rather than failing. The API…

Start a deployment that was created with create_deployment. The deployment must be in CREATED status. Once started, Staticbot provisions the repository-derived target stored on the stack. Poll get_deployment to track progress.

Switch live deployment to the project's existing builder branch (cut the cord). This stops maintaining the Staticbot mirror and can redeploy the production site. It is not an arbitrary branch picker, and no reverse action is exposed. Inspect get_connected_project_operations, explain the exact current and target branches and obtain explicit approval before confirmed=true. Forward both branch names verbatim. On a 409 inspect again and obtain fresh approval; never substitute new targets automatically. A branch switch can succeed while redeployment fails: report the returned message and redeployed…

Check and merge the migration preview branch onto the project's live mirror branch, creating the mirror if missing. This can write Git commits and trigger builds. Inspect project operations and branch previews first; explain the preview-to-live merge and obtain explicit approval. Forward the inspected live and builder branch names; a 409 requires fresh inspection and approval. The backend refuses merging into the builder branch and retains its feature/eligibility guards. A 202 may return an already-running runId: monitor get_sync_run/get_sync_run_jobs rather than queueing another action or cla…

Trigger a manual sync for a connected project. Detects changes since the last sync (new database migrations, edge function updates, frontend changes) and applies them to the target Supabase instance and the project's Staticbot-selected deployment target.

Update automatic-update flags for a deployment. Omitted fields keep their current values. IMPORTANT: Confirm the requested settings with the user before calling this tool.

Check that the Staticbot export edge function is reachable, and COMPLETE its sync step when it is. Use after the user pasted 'deploy staticbot edge function' into the Lovable AI chat (Base44: synced from GitHub). The function URL is in the MANUAL_SYNC_LOVABLE / MANUAL_SYNC_BASE44 job's inputData (function_url), or derive it as https://{sourceProjectRef}.supabase.co/functions/v1/{functionName}. Returns {status: 'ok'|'error', message, completed}. completed=true means the step is done — by this call or because Staticbot already detected the deployment — so do NOT call complete_migration_job after…