Supero

PERMANENT deploy: promote a published version to a PERMANENT public URL at <service>.supero.live (managed Cloud Run) — unlike build_deploy(target='cloud_ephemeral'), which is a ~30-min throwaway. If version_uuid/file_id are omitted, the latest published version for the project is used. Returns public_url + poll_url; poll with build_deploy_status until live, then build_smoke_test the public_url. build_teardown removes it. Requires a domain- or project-admin API key + platform cloud-deploy enablement.

IMPORT platform services into a project (e.g. 'workflows', 'email', 'stripe_checkout', 'cart', 'order', 'payment') so the app can call them and its event-bound workflows can run. Uses the platform's service import with YOUR connection's credential. Reports each service's exact outcome: imported, already imported, or FAILED with the platform's reason (schema_drift, schemas_failed, error_code, HTTP status) — a failed import is never reported as success, and you must not ship an app whose required service failed to import. After importing, set keys with build_configure_services. MCP-IMPORT-SERVIC…

Classify this project's schemas: which are connector-backed vs app-authored, and each one's access mode (sync | live-ro | live-rw | warehouse). Use it so you DON'T render create/edit UI for read-only live sources (live-ro/warehouse) or regenerate/overwrite connector-discovered schemas.

List the platform's available services/integrations from the LIVE catalog (email, sms, slack, ai, stripe_checkout, google_oauth, push_notification, …) — so the intake's 'which connections/integrations?' question is accurate and you never guess a service id. Returns each service's exact catalog `service_id` (use it verbatim in config.py `services` — e.g. 'stripe_checkout', NOT 'stripe'), category, whether it needs a key, and YOUR connection's service permissions (can_import / can_configure). Descriptive — what EXISTS, never what to use. Pass service_id for one service's config fields.

List the external DATA SOURCE types an app can connect to — its own Postgres/MySQL/MSSQL/Oracle/MongoDB, any REST API, or a Snowflake/BigQuery/Redshift/Databricks/ClickHouse/Fabric warehouse — plus the curated public-API catalog. Read this to offer a 'connect your own data' option. Flow: build_connect_data_source → build_discover_source → build_bind_data_source. See build_get_skills(doc='connectors').

List projects you can build into (uuid, name, schema_namespace, live_url).

Fetch recent Cloud Run logs for a project's deployed app — THE tool for diagnosing a failed/stalled cloud deploy or a crashing app (startup-probe timeouts, tracebacks, 'container failed to start on PORT'). Read-only; rate-limited per domain.

PLAN FIRST — turn a one-line app idea into an explicit BUILD CHECKLIST before you author anything, so a thin prompt doesn't silently skip what expert builders add (this is exactly why first-draft apps miss detail pages, tenant pickers, seed data). Deterministic, no LLM: it detects the app's VERTICAL and returns the authentic page structure + terminology for that domain, which entities need a full DETAIL PAGE, the multi-tenant login pattern (picker + tenant=''), seed guidance, and which build_get_examples to copy. Call it right after build_get_skills and BEFORE authoring.

Package + upload your authored bundle and record a version under the project. Returns version_uuid + file_id + download_url. Runs build_validate first; force=true overrides soft errors only. Provide files as {relative_path: content}.

RECOMMEND which concrete provider integrations this app needs, and WHY — the deterministic Step-2 intelligence the web wizard uses, now over MCP. Pass the app `description` + the platform `service_ids` it will use (e.g. ['cart','order']); returns GROUPED, TIERED suggestions (required/recommended/optional) with the default option flagged — e.g. cart/checkout → a payment gateway (REQUIRED; stripe_checkout default, paypal/razorpay offered), customer-facing apps → transactional email, appointments+reminders → sms. Options are drawn ONLY from the LIVE installed manifests, so it can't suggest a prov…

DESTRUCTIVE (DOMAIN-admin keys only): completely replace a DEV-mode project's app — wipes its data (retains credentials, API keys, namespace, tenant). Refused if mode='live'. Requires confirm_project_name to match. If you pass files, they are VALIDATED before any wipe (a bad bundle is a no-op) and published after; otherwise wipe-only, then call build_publish.

Trigger a SYNC RUN on a data connector and return the run id. MCP-created connectors are trigger:manual, so a mode='sync' binding copies NO rows until a run executes — call this after build_bind_data_source (and again whenever the source data changes). Live-read/warehouse bindings don't need runs (they read the source directly).

Set a project's build mode. 'dev' (default) allows COMPLETE REPLACE (wipe data, keep credentials); 'live' protects it. Switch to dev before replacing, to live when it's in production.

VERIFY a DEPLOYED app actually works (not just 'running'). HTTP-checks the live URL: root loads with a title, app.js is your bundle (not a stub) and dismisses the boot splash, config.js namespace matches the project; optionally logs in and reads an entity to confirm data + no namespace ambiguity. Pass url= (from build_deploy_status) or poll_url=. THE post-deploy gate — run it after every deploy.

PUB-1a: get the out-of-band UPLOAD endpoint for a LARGE app bundle that won't fit inline (the model's max OUTPUT tokens cap `files`/`files_b64gz`, so big apps otherwise have to be truncated/minified). Upload a gzip(json {path:content}) blob to the returned URL with your OWN key, then pass the returned file_id as `files_ref` to build_validate / build_publish / build_doctor. Bundle size then no longer depends on any token cap.

Tear down a project's live deployment — BOTH the permanent (build_go_live) app and the ephemeral preview — DELETEing the managed Cloud Run services and freeing their URLs. Idempotent: a project with nothing deployed returns stopped=true. ONLY manages Supero-hosted apps — a project deployed to your own AWS/GCP is refused, not silently reported stopped. Check `stopped`: false means the teardown was INCOMPLETE and the app may still be serving (and billing) — re-run it, do not report success. Requires a domain- or project-admin API key.

Update a project's metadata (display_name, description, show_public, live_url).

Validate a locally-authored bundle against the live platform BEFORE publishing. AST-only (your code is never executed). Checks manifest, syntax, import-safety, config exports, schema validity, and namespace==project schema_namespace.

ACCEPTANCE TEST of your app's running PREVIEW (after build_deploy, before build_go_live). Where build_audit reads the code, build_verify USES the deployed preview like a buyer would, with throwaway test accounts (verify-<rand>@example.com, deleted afterwards): health (serves, app.js = the published version, boots, API reachable); accounts (sign-up, login right after sign-up, login, forgot-password reachable); the role permission matrix (per end-user role x schema: the declared policy holds, server-owned fields such as status/totals/payment state cannot be written by the user, fulfilment record…

Resolve your API key's scope: role (domain_admin/project_admin), domain, whether you can create projects, and your plan. Call this to decide the flow.

Cancel a running connector execution.

Disable a connector.

Trigger schema/metadata discovery for a connector.

Get discovery results.

Get discovery execution status.

Enable a connector for scheduling.

List available connector plugins.

Trigger a manual connector sync execution.

Get connector status and recent executions.

Test an existing connector's connectivity.

Test a connector configuration.

Create a new object in the current domain. Use schema_list to see available types and their fields.

Delete an object from the current domain.

Get a specific object by UUID from the current domain.

Search/list objects of any type in the current domain. Use schema_list first to discover available object types. System types: project, tenant, user_account, api_key, connector, audit_log, schema_registry, client_sdk, connector_execution, connector_plugin. Domain types vary per domain (e.g. customer, invoice, appointment, vehicle).

Update an existing object in the current domain.

Link schemas to a project. Accepts schema UUIDs or names.

Check if the current user has a specific permission.

Get current user's role, permissions, and scope.

Delete a schema from the domain. Use with caution.

Get full details of a specific schema by UUID. Returns the complete schema definition including all attributes and metadata.

List all existing schemas in the current domain.

List schemas linked to the current project.

Save/upload schemas into a project. Schemas are validated before saving and linked to the project. Returns the saved schemas with their UUIDs; skipped schemas carry the platform's reason. IMPORTANT: Pass FLAT schema objects directly — do NOT wrap in schema_content. The tool handles schema_type detection and wrapping automatically. Required fields: name, namespace, parent_type, attributes. Set namespace to your app's namespace (e.g. 'shop'); the schema is stored as namespace:name. Mark required attributes with "mandatory": true. Supported attribute types: 'string' for text, 'float' for de…

Update an existing schema definition.

Validate schemas before saving. Checks for conflicts with existing schemas, circular dependencies, reserved names, and parent_type correctness. Always validate before saving!

Get download URL for an SDK.

Generate client SDKs for the domain's schemas.

List available SDKs for the current domain.

Check SDK generation request status.