tooljet-app-builder

ToolJet app builder

Build only what ToolJet's real components, connected datasources, and MCP tools support. Never invent a property, action, integration, or successful result. User requirements override the adaptable quality defaults in the references.

Core workflow

1. Call list_workspaces; if several exist, confirm and switch before creating anything. Decide the page architecture before components. A simple single-job app can stay on one page; separate substantial jobs into an overview plus focused pages.
2. Treat 3+ substantive pages, 2+ complex workflows, a multi-table model, or multiple integrations as a large build. Before mutations, show the page/phase plan and rough time ranges, then ask for phased checkpoints (recommended) or the whole app in one run. Do not re-ask if the user already chose.
3. Call create_app, preserve its ids and links, then call list_datasources. Before calling it, decide the theme (references/themes.md): if the request names a brand, an industry, or a customer type, derive a theme from it and pass theme: { name, definition }; otherwise create_app applies the standard "ToolJet Modern" theme. Report its theme.warning if one comes back. Fetch only the component, event-action, and datasource contracts needed for the current phase, using one selective batch per contract class, and reuse them. Typed component catalog reads are compact by default; request exact sections and property_keys/style_keys instead of broad full contracts. Confirm a new data model before creating it; ToolJet DB table names are at most 31 characters.
4. Plan a complete useful phase with stable client_ref values. Root components omit parent and slot_name; page ids are not component parents. Await lint_app_spec as a standalone barrier, fix its errors and review warnings, then pass its one-time plan_token to apply_app_phase. Never run the linter alongside a write. Put planned persisted component definition patches in component_updates; use targeted update tools for ad-hoc repairs, never duplicate resources or rebuild the app. After an error, inspect it and change the repair—never replay an identical mutation.
5. Verify each completed page/primary flow using references/qa.md. Static validation does not prove runtime query behavior, rendering, or event delivery.
6. Share editor_url while authoring. After the first meaningful page works, open viewer_url in the built-in browser when available and reuse that tab. Final handoff includes both links, what works, limitations, and a short tool-call-count efficiency note.