DEV Community: ToolJet

Build a Security Questionnaire App With ToolJet MCP

Athulya R — Thu, 01 Oct 2026 12:17:27 +0000

Introduction

Every enterprise deal brings a long security questionnaire, and most security and sales engineering teams still answer it from scratch. This tutorial shows how to build a security questionnaire app with ToolJet MCP for a B2B software company in Dublin. The app keeps an approved answer library with owners and review dates, matches each question in an uploaded questionnaire to the closest approved answer, and exports the completed pack as a PDF filled into the customer's own form. An AI agent generated it as a structured ToolJet application, with data, queries and interface together, so the team can keep editing it as the process changes.

The pack builder for a Northwind Bank questionnaire: 21 reused, 1 tailored and 3 new answers, 100 percent complete, with the pack register below.

The answer library with owners, review dates and stale flags, filtered by category and review status.

Library submissions from pack work, waiting for the compliance lead to approve or reject.

How the Answer Library and Pack Builder Work

The first page is a working answer library with filters for category and review status, a stale flag on older entries, and an editor that opens the selected answer with its review cycle and history. The second page is the pack builder, where you enter the customer and deal, upload a questionnaire, and match each question to the closest approved answer. Unmatched questions stay visible at the top, each match shows a confidence score, and the sales engineer can accept the suggestion, swap in another library answer, tailor the wording for that pack, or submit a new answer for review. A summary strip tracks reused, tailored, new, and unmatched work, then the finished pack downloads as a PDF filled into the customer's own form.

Searchable approved answer library with category and review status filters
Stale flags, owner fields, and review dates on each answer
Questionnaire upload, parsing, and matching with confidence scores
Pack-level tailoring, new-answer submission, and review handoff
Filled PDF export plus a pack register and activity log

Get Started With ToolJet MCP

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Prompt to Rebuild the App

The build took several passes before the shape settled. The requirements are consolidated into one prompt here, so you can reproduce the same app in a single shot.

Build a polished internal app called Security Questionnaire Desk in ToolJet.

Keep it to two pages: Answer Library, showing approved answers with search, category and review status filters, a stale flag, and an editor with history; and Pack Builder, where a sales engineer uploads a customer's questionnaire, matches each question to the closest approved answer with a confidence score, groups unmatched questions at the top, and downloads a filled PDF.

Use a muted Nordic palette, calm and restrained, with dense two-column working areas, compact rows, clear hierarchy, and status colours only where they help.

Use PostgreSQL for the approved answer library, answer history, roles, library submissions, and pack items. Use ToolJet DB for the pack register and the pack activity log.

The compliance lead is the only person who can approve, change, or re-approve a library answer, and that rule should be enforced in the database. Sales engineers can build packs and tailor wording for one customer without changing the master answer.

How ToolJet MCP Builds the Questionnaire App

ToolJet MCP takes the questionnaire requirements and works through the whole application, so the data model, pages, components, queries, and wiring land as one structured ToolJet application inside ToolJet, not as a loose bundle you assemble later. Enterprise app building does not end at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change are the rest of the job, and the generated app sits on a runtime that carries those where supported rather than handing you a codebase to operate yourself. The path stays open, so you can move from AI generation to visual editing and code when a specific rule or pack behaviour needs it.

The File Upload Issue We Fixed

The upload step looked broken because the file picker refused every questionnaire file. The picker had been limited to image/*, so PDFs never reached the parser. Switching the control to PDF, XLSX, and CSV fixed the flow.

PostgreSQL and ToolJet DB Tables Behind the App

The app ended up with seven tables. cqa_answers stores the approved answer library with the owner and last reviewed date, cqa_answer_history records each change, cqa_roles maps the compliance lead and sales engineer roles, cqa_submissions holds new answers waiting for review, cqa_pack_items stores each questionnaire item and its match, and cqa_packs plus cqa_pack_log live in ToolJet DB for the pack register and activity trail.

Page	Components	What they cover
Answer library	28	Answer table, filters, answer editor with history, submissions review
Pack builder	18	Upload, matching table, answer panel, summary, pack register

What ToolJet MCP Generated

Metric	Result
Pages	2
ToolJet DB + PostgreSQL tables	7
Queries	30
Components	46
Code files to maintain	0
Repair cycles	2
Final validation	0 errors

The components ToolJet MCP created, in the ToolJet inspector

Industries That Answer Security Questionnaires

Any B2B software or services company that sells to regulated buyers runs this process: SaaS vendors answering bank and insurer due diligence, managed service providers handling NIS2 and DORA supplier reviews, health tech companies answering hospital procurement, and fintechs filling out partner bank onboarding forms. The common thread is a small security team answering the same questions for many deals.

Roles and Access in the Built App

Two roles, stored in PostgreSQL. The compliance lead is the only person who can create, change, re-approve or approve answers in the library, and the database functions refuse those writes from anyone else. Sales engineers can search the library, build packs, swap or tailor wording inside a pack and submit new answers for review, but tailored wording stays in the pack and never changes the master answer.

ToolJet Database: Built-In PostgreSQL Storage for Full-Stack Apps

A Security Questionnaire Desk app needs somewhere to keep its records, and ToolJet Database gives it a built-in, PostgreSQL-backed database with no separate server to provision or connect. Builders can create tables, relate them and query them from the same platform where the app is built.

The pack register and activity log live in ToolJet DB, while the answer library stays in PostgreSQL, so the team keeps the working records inside the same app without a separate database server.

ToolJet Database: Built-In PostgreSQL Storage for Full-Stack Apps

Tables, Data Types and Relationships

ToolJet Database overview: keep tables in a secure database that is only accessible within your ToolJet organization, on both ToolJet Cloud and self-hosted deployments.
Database editor: create tables and edit, search, filter and sort rows in a spreadsheet-like interface.
Supported data types: serial, varchar, int, bigint, float, boolean, date with time and jsonb columns, with an automatic serial id primary key on every new table.
Foreign keys: link tables and choose what happens to a row when the referenced row is updated or deleted, keeping referential integrity.

Querying ToolJet Database from Apps

GUI and SQL queries: list, filter, sort, aggregate and group rows in GUI mode, or write SQL directly in the SQL editor.
Works like any data source: ToolJet Database queries bind to components and events the same way as other data sources, without connection setup.
Self-hosted configuration: on your own deployment, ToolJet Database runs on a PostgreSQL database you configure and is exposed to the app through PostgREST.
Schema export: export table schemas to a JSON file.

This lets the Security Questionnaire Desk app go full stack in one platform, with data, logic and UI together, while external databases can still be connected later. Table limits vary by plan on the ToolJet pricing page.

Enterprise Features for Your Security Questionnaire App

A security questionnaire app handles approved answers, customer details, and review notes. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a new answer is submitted, post a Slack message to the compliance lead, send a Gmail message to the sales engineer, and write the review note back to cqa_submissions.

Final Takeaways

This build gives security and sales engineering teams one place to maintain approved answers, compare uploaded questionnaires against that library, and export a filled PDF for the customer form. The result is a repeatable flow for sales engineering and compliance, instead of rewriting the same material for each deal. ToolJet MCP turns the requirements into a real, editable ToolJet application, so the team can keep adjusting the library, matching behavior, and pack output as the process changes. That is the useful part of the build, because the app stays alive after the first pass.

Try ToolJet MCP

Build your own security questionnaire desk with ToolJet MCP, then request a ToolJet demo for your answer library and pack flow.

FAQs

What is ToolJet MCP in this build?

ToolJet MCP takes the questionnaire requirements and turns them into a structured app inside ToolJet. For this desk, the library, pack builder, matching logic, and PDF output live together instead of becoming a loose codebase you have to assemble elsewhere.

What does the answer library page show?

It shows the approved answer set with search, category filters, review status, and a stale flag for items past their review cycle. Opening a row reveals the answer text, owner, review interval, keywords, and change history in one editor.

How do you reproduce the build from the prompt?

Use the prompt in this article as the full specification and build the two pages, tables, and matching rules in one pass. The consolidated prompt captures the page layout, review flow, and PDF output so you do not have to reconstruct the shape from notes.

Do you need to write code for questionnaire matching?

You do not need to handwrite the whole app. The screens come from visual components, while parsing uploaded files, scoring matches, and filling the exported PDF use code where the workflow needs logic in this build.

What happens to the app after the agent finishes?

The generated app stays as a structured ToolJet application, not a one-off code dump. The runtime carries the data connections, workflows, permissions, deployment, and ongoing change where supported, so you keep editing the same app as the process changes.

Can the app use PostgreSQL and ToolJet DB together?

Yes. The answer library, history, roles, submissions, and pack items live in PostgreSQL, while the pack register and activity log sit in ToolJet DB, which keeps operational state separate from the review content for the team.

Can several teammates work on the same app at once?

Yes. ToolJet supports multiplayer editing, so several builders can work on the same app, with versioning and Git sync. In daily use, the compliance lead maintains the master answers while sales engineers build packs from them.

Build a Bank vs ERP Reconciliation App with ToolJet MCP and Jev

Athulya R — Wed, 30 Sep 2026 12:04:25 +0000

Introduction

The Reconciliation Workbench is a two-page ToolJet app for the finance operations team, built by a coding agent through ToolJet MCP. Bank lines and ERP entries sit in PostgreSQL, analyst decisions sit in ToolJet DB, and Jev, TypeSafe's model, triages each break at runtime through the typesafe datasource. The analyst accepts or overrides Jev's suggestion, so nothing clears automatically. By the end you will see the Break queue, the Close summary, the triage flow and the data model behind them.

The Break queue page lists unmatched bank versus ERP breaks, with Jev's triage result beside the selected break.

The Close summary page shows unexplained value by break type, ageing and the Agreed or Overridden decision log.

How the Break Queue and Jev Triage Work

The home page centers a dense break queue with filters and a KPI strip. Opening a row shows the bank line beside the ERP entry. Triage with TypeSafe asks Jev, through the TypeSafe datasource, three typed questions: reason (a choice), severity (a Low, Medium or High score) and auto_clear (yes/no, meaning Jev suggests the break could clear without a journal). auto_clear is only a suggestion: the app does not clear or post any financial record automatically. The panel shows the cause with its confidence, plus the tokens used per call. Jev's output is a suggestion. The analyst leaves the cause blank to keep it, or picks another cause, which is saved as an override with a resolution and note. The Close summary then shows unexplained value by break type, an ageing chart, the agreement KPI and a decision log marking each decision Agreed or Overridden.

Break queue with filters, KPIs, and side-by-side break detail
Jev triage with cause, confidence, severity and auto-clear (live typesafe datasource call)
Accept or override the suggested cause and save the analyst note
Close summary with unexplained value, ageing, and decision log
PostgreSQL for bank and ERP data, ToolJet DB for decisions

Set Up ToolJet MCP and the TypeSafe Datasource

Want to build it yourself? Read the overview and use the ToolJet MCP repository for setup and supported agents. You also need a TypeSafe datasource in the workspace; the TypeSafe datasource guide covers its setup and API key options.

The Consolidated Build Prompt

The build took several passes before the shape settled. The requirements are consolidated here into one prompt that could have been used from the start, so you can reproduce the app in a single shot.

Build a 2-page bank-versus-ERP reconciliation app in ToolJet for the finance operations team at Fjell & Fura AB, covering three accounts. Use only ToolJet native components on a muted Nordic, hygge-inspired theme (functional beauty, restrained elegance, natural materials, soft neutrals, cozy minimalism). Keep it enterprise grade, information dense with little whitespace, and with slightly larger font sizes.

Data: use PostgreSQL (datasource postgresql_fleet) for both sides. The bank feed stands in for Snowflake, which is not connected, so label it 'Snowflake stand-in'. Create rw_meta, rw_ledger and rw_bank_txns plus a view rw_v_recon that full-outer-joins bank and ERP on invoice reference and account and shifts dates by the days since seeding. Seed synthetic data only. Use ToolJet DB table rw_decisions for the AI cause, severity and auto-clear result plus the analyst's cause, resolution and note.

Triage: use the existing typesafe datasource (TypeSafe AI, Jev model) with the evaluate operation. Send the break as state and ask three typed questions: reason (choice: timing, FX difference, bank fee, duplicate, missing entry, keying error), severity (score: Low, Medium, High) and auto_clear (yes/no). Show the returned confidence and the input and output tokens used.

Page 1, Break queue (home): a KPI strip, filters and the list of breaks. Selecting a break shows the bank line beside the ERP entry and a Triage with TypeSafe button. The analyst can accept the suggested cause (leave the cause dropdown blank to keep it) or pick a different one, which is saved as an override, with a resolution and note.

Page 2, Close summary: unexplained value by break type, an ageing chart, an agreement KPI and a decision log marking each decision Agreed or Overridden.

How ToolJet MCP Built the Workbench

ToolJet MCP connects the coding agent to the ToolJet workspace, so the pages, components, queries and the wiring between them land as one structured ToolJet application. It is a build-time tool: Jev did not build the app and only runs inside it, through the typesafe datasource. The path stays open, so you can move from generation to visual editing and then into code when a case needs it.

The Cause Override Issue We Fixed

After you chose an override, the cause dropdown jumped back to Jev's suggested value, so the analyst's pick did not stick. A reactive default was resetting the dropdown. Removing it fixed the problem. A blank dropdown now means "keep Jev's cause" and shows the placeholder Keep: [AI cause].

Tables and View Behind the Reconciliation Workbench

The app uses four tables and one view across two datasources. In PostgreSQL, rw_meta stores reconciliation metadata and account settings, rw_ledger holds ERP entries, rw_bank_txns holds bank transactions (the Snowflake stand-in), and the view rw_v_recon joins the two into the break list. In ToolJet DB, rw_decisions stores Jev's output and the analyst's decisions. All data is synthetic.

Page	Components	What they cover
Break queue	15	KPI strip, filters, break list, bank and ERP detail, triage and decision controls
Close summary	9	KPIs, unexplained value and ageing charts, decision log

What the Build Produced

Metric	Result
Pages	2
Tables	4
Views	1
Queries	10
Components	24
Repair cycles	1

The components ToolJet MCP created, in the ToolJet inspector

Industries That Run This

Finance and accounting operations teams that reconcile bank statements against an ERP ledger, including shared service centres, treasury and month-end close teams in financial services, retail and logistics.

Who Gets Access To The Built App

The app is built for finance analysts. No group-based permission rules were configured in this build, so access follows the workspace's app access settings. Restricting who can save decisions is something to confirm before production use.

GitSync, Version Control and CI/CD Releases in ToolJet

A Reconciliation Workbench app keeps changing after launch, and ToolJet gives it a real software lifecycle: saved versions you can release and roll back, GitSync to a Git repository, and an API that drives releases from CI/CD pipelines.

When the finance team changes a rule in the reconciliation view, GitSync moves that edit from draft to release with a clear review path. If the change misbehaves, rollback returns the app to the last safe version before analysts lose trust in the queue.

GitSync, Version Control and CI/CD Releases in ToolJet

Git Version Control with GitSync

GitSync overview: sync workspace apps with a Git repository for backups, a versioned history and moving apps between development, staging and production instances, using cloud or self-hosted Git providers and a custom branch.
Git connection methods: connect GitHub or GitLab over HTTPS, or any Git provider such as Gitea over SSH.
Pushing changes to Git: commit with a message from the GitSync button, with automatic commits on app rename, version updates and environment promotion.
Pulling changes from Git: import the latest commit to restore a backup or pick up another developer's work.

Releases, Rollback and CI/CD Automation

Version control: edit in a draft, then save a fixed version that can be promoted, released or used for rollback.
Release and rollback: release a saved version to end users from Production, and restore a previous stable version instantly while the app URL stays the same.
GitSync API for CI/CD: push versions, create apps from Git, promote to the next environment and set the live release from Jenkins, GitHub Actions or GitLab CI.

This lets the Reconciliation Workbench app ship changes through review and recover quickly from a bad release. Version control starts on the Pro plan and GitSync on the Team plan, while the GitSync API is a self-hosted feature of the ToolJet Enterprise plan.

Enterprise Features for Your Bank Reconciliation App

A reconciliation workbench handles bank transactions, ERP ledger entries, and analyst decisions. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

You could add a notification layer with ToolJet Workflows. For example, a workflow could fire when a break is overridden, post to the manager in Slack, email the analyst through Gmail, and write the decision back to rw_decisions.

Final Takeaways

The Reconciliation Workbench shows how ToolJet MCP can turn a finance review process into a structured application with a clear decision trail. The break queue keeps the bank and ERP lines side by side, Jev's triage suggests a cause the analyst can accept or override, and the close summary turns saved decisions into a readable view. The bank feed is a PostgreSQL stand-in for Snowflake and the data is synthetic. Because the output is a real ToolJet application, the team can keep changing the workbench as reconciliation rules change.

Try ToolJet MCP

Build a reconciliation app with ToolJet MCP for your own finance data, then request a ToolJet demo.

FAQs

What does ToolJet MCP do for a reconciliation workbench?

ToolJet MCP connects a coding agent to the ToolJet workspace so it can create the break queue, detail pane, triage flow and summary page. Here the result is a working reconciliation workbench for Fjell & Fura AB, using synthetic data.

What does this app show for each break?

The bank line beside the ERP entry, plus Jev's suggested cause with confidence, a severity score and an auto-clear yes/no. The analyst accepts the suggestion or overrides it, and the decision is saved.

Is Jev connected live, and does it clear breaks automatically?

Jev runs live through the typesafe datasource during triage. Its output, including auto_clear, is a suggestion only. The analyst decides and saves, and the app does not clear or post any financial record automatically.

How do you reproduce this reconciliation app?

Use the prompt in this article with ToolJet MCP and a typesafe datasource in the workspace. It describes the pages, the rw_ tables and view, the rw_decisions table and the three triage questions.

Do you need to write code to build it?

The agent built the workbench through ToolJet MCP without hand-writing the app. You can still move into code or visual editing when a case needs it.

How is the agreement KPI calculated?

It is the share of saved decisions where the analyst kept Jev's cause. In testing it read 75%, which was 3 of 4 demo decisions.

Build a Supplier Product Import App with ToolJet MCP

Athulya R — Tue, 29 Sep 2026 12:10:37 +0000

Introduction

In this walkthrough, you'll learn how to build a supplier spreadsheet import workflow with ToolJet MCP for a wholesale operations team in Manchester. The app maps supplier data to product fields, validates changes, stages updates for review, and gives authorized users a controlled path to commit them. Instead of manually cleaning spreadsheets or maintaining a separate code workflow, the team can manage data, queries, validation, and review in one ToolJet application. You'll also see how the agent-generated app handles the complete import workflow from file upload to final approval.

Review changes: counts for new, changed, unchanged and rejected rows, and every changed field with current and incoming value and the percentage move

Map columns: the supplier's saved mapping pre-fills each column, beside a mapping check of which of our fields are covered

Cannot import: only the failing rows in an editable grid, with the problem cell highlighted and a re-check for just those rows

Confirm: what will be written to the product master, the largest price moves, and a steward-only commit behind a review tick

What We're Building

The screen is a four-step workspace with a file summary beside the current step and a history pane underneath. Upload accepts .xlsx, .xls, or .csv files, shows the chosen supplier, and keeps the original row numbers ready for review. Map lines up file columns against internal fields with labels that show whether a mapping is saved, detected, or changed. Review splits the result into product changes, new products, and rejected rows, then lets you edit only the bad cells and re-check them. Confirm shows the final import summary and keeps commit locked until the review tick is set. The reviewer can trace each rejected row back to the source file.

Drop in .xlsx, .xls, or .csv files and keep the original row numbers for review
Reuse a supplier's saved mapping and flag Saved, Detected, or Changed values in the mapper
Preview added products, field-by-field changes, and rejected rows before anything is written
Fix failed rows in place, then re-check only the corrected records
Restrict commit and mapping-save actions to data stewards while keeping past imports visible

Build a Supplier Product Import App with ToolJet MCP

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated ToolJet MCP Build Prompt

The build took several passes across layout, data, and validation before the app settled into one flow. The requirements are now consolidated into the prompt below, so you can reproduce the same importer in a single shot.

Build a single-page supplier product import app in ToolJet for the operations team of a Manchester wholesale distributor.

Keep it as one dense workspace with four steps: Upload, Map, Review, Confirm, plus an import history pane. Upload accepts supplier spreadsheets and shows the selected supplier and file summary. Map aligns incoming columns to internal fields and makes saved mappings visible. Review previews added products, field-by-field changes, and rejected rows, and lets users fix bad cells in place before re-checking only those rows. Confirm shows what will be written and requires the reviewer acknowledgement before commit.

Use a Nordic Steel Blue visual style: cool greys, slate headers, restrained blue accents, compact rows, strong hierarchy, and status colours only where they help.

Use PostgreSQL for the product master and history, and ToolJet DB for suppliers, saved mappings, and import field definitions. Model imports so the preview and past runs come from stored records, not mutable status fields.

Only data stewards can save mappings or commit an import. Every commit must re-check that role, reject stale previews, and record adds, changed fields, and rejected rows in the history.

How ToolJet MCP Builds the Import App

ToolJet MCP works through the whole application, not just the visible page: the data model, queries, components, and wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, because data connectivity, permissions, deployment, and ongoing change are part of the job, and the generated app sits on a runtime that carries those where supported instead of handing you a codebase to operate yourself. The path stays open: AI generation, then visual editing, then code when a case needs it.

The Mapping Validation Issue We Fixed

Changing a column mapping did not immediately refresh the mapping check, so the review step could still look valid after two columns pointed at the same field. The cause was the check not rerunning on dropdown edits, and the fix made the warning update as soon as the mapping changed.

Supplier Product Import Data Model

The app ended up with 8 tables in two groups. The PostgreSQL group covers spi_products, spi_categories, spi_app_roles, spi_import_runs, and spi_import_changes, while the ToolJet DB group covers spi_suppliers, spi_saved_mappings, and spi_fields.

Page	Components	What they cover
Home	50

What ToolJet MCP Generated

Metric	Result
Pages	1
ToolJet DB + PostgreSQL tables	8
Queries	16
Components	50
Code files to maintain	0
Repair cycles	2
Final validation	0 errors

The components ToolJet MCP created, in the ToolJet inspector

Who Can Use This Supplier Import App

Wholesale and distribution businesses, cash-and-carry and foodservice suppliers, retail buying and merchandising teams, and any operations or master-data team that receives product, price or catalogue updates from many suppliers as spreadsheets and needs them checked before they reach the product master.

Control Access with Roles and Permission

As built, roles come from the signed-in user's email in a PostgreSQL roles table. Two data stewards can commit an import and save a supplier's mapping; ToolJet query permissions restrict the commit and mapping-save queries to those two users, and the commit function in the database checks the steward role again before writing anything. Everyone else with access to the app can upload a file, correct the mapping, see the full preview, fix rejected rows and browse the import history, but cannot commit.

Add SSO and SCIM for Enterprise Access

A Supplier Product Import app should use the company login your team already has, and ToolJet supports single sign-on (SSO) through SAML, OpenID Connect (OIDC) and LDAP, plus SCIM 2.0 for automated user provisioning. People sign in with their identity provider account, and access follows your directory instead of a separate password list.

When a steward joins or leaves the operations team, directory changes can flow into the same access controls that protect this importer. SSO and SCIM keep their access aligned with the company directory without separate hand edits.

Single Sign-On and SCIM User Provisioning in ToolJet

Supported SSO Protocols (SAML, OIDC and LDAP)

Workspace admins turn each method on under Workspace settings > Workspace login, as described in the ToolJet SSO overview:

SAML single sign-on: connect providers such as Okta, Active Directory Federation Services, Auth0 or Azure AD by pasting your identity provider metadata, with optional group sync from a group attribute.
OpenID Connect: use Azure AD, Google or Okta with the Authorization Code or Authorization Code with PKCE grant, configured per workspace or for the whole instance. On the Enterprise plan you can set up multiple OIDC providers side by side, and users pick theirs on the sign-in page.
LDAP authentication: sign users in against your directory server using Base DN search, CN or UPN usernames, optional SSL certificates and group sync on every login.

Automated Provisioning with SCIM 2.0

SCIM user and group provisioning: connect Okta, Azure AD, OneLogin or another identity provider to create users when they join, update names, emails and role mappings in real time, and archive users as soon as access is revoked.
Server-side setup: SCIM is switched on with environment variables on your ToolJet deployment and accepts Bearer token or Basic authentication.

With SSO and SCIM in place, onboarding and offboarding for the Supplier Product Import app happen in your identity provider rather than by hand. SAML, OIDC and LDAP are available from the Team plan, and SCIM provisioning is part of the ToolJet Enterprise plan.

Enterprise Features for Your Supplier Import App

A supplier product import app handles price files, product master data, and steward approvals. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

You could add it with ToolJet Workflows. For example, a workflow could fire when an import is committed, post a Slack message to the operations channel, send a Gmail message to the steward, and write the decision back to spi_import_runs.

Final Takeaways

A supplier product import app can turn a manual spreadsheet process into a controlled workflow for mapping, validation, review, and approval. This ToolJet MCP build takes supplier files from upload to staged product changes, lets users correct rejected rows, and restricts final commits to authorized data stewards. The result is a working ToolJet application with the database tables, queries, components, permissions, and import history needed to support the workflow. For wholesale, distribution, retail, and master-data teams, the same pattern can be adapted to existing product databases and supplier processes. ToolJet MCP provides the starting point, while the resulting app remains editable as requirements change.

Try ToolJet MCP

Build a supplier product import app with ToolJet MCP for your catalog files, then request a ToolJet demo.

FAQs

What does ToolJet MCP do in this build?

ToolJet MCP is the bridge that lets an agent turn the prompt in this article into a real ToolJet application. It threads the tables, queries, and page wiring into one result, so the importer arrives as a connected app rather than disconnected pieces.

What does the supplier product import app do?

It loads supplier spreadsheets, maps incoming columns to your fields, previews added rows, changed fields, and rejects, and lets a steward commit only after review. It also keeps supplier mappings and import history so the next file starts from known rules.

Can I reproduce this importer from the prompt in this article?

Yes. The consolidated prompt in this article is written so you can start from a single specification and recreate the same importer in one pass. The walkthrough shows the finished shape, so the prompt has a clear target.

Do I need to write code for the parsing and validation?

Not for the main flow. Native ToolJet components handle the workspace, while custom code only appears where parsing, cleanup, or validation needs it. That keeps the import logic inside the app instead of scattered across separate files.

What happens to the app after the agent finishes?

The agent leaves you with a ToolJet application that stays in the workspace, and the runtime continues to handle the data connections, permissions, and change management the app needs where supported. You keep editing the same app instead of starting over from a codebase.

Can I use my own PostgreSQL data and saved mappings?

Yes. This build uses PostgreSQL for the product master and import history, and ToolJet DB for supplier and mapping configuration. The same pattern fits your own catalog when those records already live in a database.

Can several people work on the same importer?

Yes, the app can be shared with different access levels, and steward-only actions stay restricted. That lets one person test mappings while another reviews imports without crossing the commit boundary, and the shared history keeps handoff simple.

Build a Contract Obligations Review App with ToolJet MCP

Athulya R — Mon, 28 Sep 2026 11:14:55 +0000

Introduction

Here is how to build a contract obligations review app with ToolJet MCP for the legal operations team at a Singapore property group. The app keeps each contract PDF beside the obligations extracted from it, and it tracks clauses, act-by deadlines, comments and the approval record in one place. An agent generated it as a structured ToolJet application, with its data, queries and interface kept together, so the team runs and edits a real app instead of maintaining a code drop. This article walks through the screens, the tables and the build, and gives you the consolidated prompt so you can reproduce it in one shot.

Review: the executed lease beside the obligations extracted from it, each with an owner, last day to act and notice window, plus comments and the approval record

Obligations calendar: open obligations by last day to act, flags for items inside their notice window, a month view and commitments per owner

Contract register: every contract with its counterparty, business owner, status, expiry and next act-by date

Add obligation: clause, PDF page, category, owner, deadline, notice period, recurrence and status for a new obligation

What We're Building

The Review page keeps the contract PDF on one side and the obligations table on the other, so clause text and extracted duties stay in view together. Clicking a row jumps the PDF to the source clause and highlights that passage. A comment panel follows the selected obligation, and the approval timeline sits under the review panel so decision history remains visible while the contract is open. The calendar page groups action dates by owner, and the register page gives search, type, status, and property filters for the wider portfolio.

PDF beside obligations with clause-level jump and highlight
Per-obligation comments with an append-only approval timeline
Calendar grouped by business owner with act-by dates
Searchable contract register with type, status, and property filters
Role-aware review flow for legal reviewers, owners, and General Counsel

Build a Contract Obligations Review App with ToolJet MCP Follow-Along

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes to settle the screens, data model, and review flow. The requirements are consolidated into one prompt that could have been used from the start, so you can reproduce the app in a single shot.

Build a 3-page Contract Obligations Review app in ToolJet for the legal operations team of a Singapore commercial property group that manages several hundred lease and vendor agreements.

Use top navigation and native ToolJet components where they fit. Make the interface feel like a quiet institutional legal portal on a Swiss grid, with light and dark mode, a pale background, dark slate text, subtle borders, deep navy accents, no shadows, no rounded corners, dense two-column layouts, compact type, bold table headers, and uppercase monospace clause tags.

Store the app in ToolJet DB using six clr_ tables: clr_people, clr_contracts, clr_documents, clr_obligations, clr_obl_comments, and clr_approval_log. Seed a realistic fictional Singapore portfolio of about 14 leases and vendor contracts with around 80 obligations, some with 90-day notice periods.

Use the signed-in user's email to determine role. Legal reviewers can add and edit obligations, comment, and submit a contract to General Counsel. Business owners see only the contracts and obligations they own. Only General Counsel can approve, and a contract becomes Active only on approval. Restrict write queries server-side to the right users, with decision queries limited to General Counsel.

The Review page shows the contract PDF beside a table of obligations. Clicking an obligation jumps the PDF to the source clause and highlights it. When no real PDF exists, generate one from clause text. Each obligation has its own comment thread. Add and edit obligations in a modal. Under the obligations, show approval history as a timeline. The history is append-only and records every submission, review note, and decision with name, role, and timestamp. General Counsel can approve or request changes. Approval freezes current obligations as a numbered version. Any later add or edit is logged as an amendment against that version and tagged on the row.

The Obligations calendar shows the last day to act, which is deadline minus notice days. Show a month calendar and an agenda grouped by business owner, with per-owner summaries. Mark overdue items, items inside their notice window, and items due within 30 days. Filter by owner, time horizon, and whether to show only items needing action or only notice obligations.

The Contract register is a searchable table of visible contracts, filterable by type, status, and property. Show the ref, counterparty, business owner, status, expiry, and next act-by date, with a button that opens the contract on the Review page.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not the screen: the data model, queries, component tree, and wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, data connectivity, workflows, permissions, deployment, and ongoing change are the rest of the job, and the generated app sits on a runtime that carries those where supported instead of handing the team a codebase to operate themselves. The path stays open, so AI generation, then visual editing, then code when a clause jump or frozen version rule needs it.

The One Thing That Broke

The Review page first showed "No contract" even though the contract picker and obligations list had loaded. The PDF viewer was bound to an object literal that ToolJet resolved to an empty object, so the pane had no document data until the binding was corrected.

Data Created

The app ended up with six tables. clr_people stores the people and roles, clr_contracts tracks each agreement and its current state, clr_documents holds clause text and the optional PDF link, clr_obligations captures each duty, clr_obl_comments stores reviewer comments, and clr_approval_log keeps the append-only approval history and frozen approved versions.

Page	Components	What they cover
Review	38	contract picker and actions, PDF viewer with clause highlight, obligations table, per-obligation comments, approval timeline, add/edit obligation and approval-step modals
Obligations calendar	11	owner, horizon and show filters, legend, month calendar, owner-grouped agenda and per-owner summary
Contract register	6	type, status and property filters and a searchable contract table with next act-by dates and a Review button

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	6
Queries	28
Components	55
Code files to maintain	0
Repair cycles	1

Industries That Run This

Commercial and retail property groups, REITs and landlords, facilities management firms, and any legal operations or contract management team tracking lease and vendor obligations, such as renewal options, notice periods, reporting duties and payment milestones, across hundreds of agreements.

Who Gets Access To The Built App

As built, roles come from the signed-in user's email in the app's own people table. Legal reviewers and General Counsel see every contract, add and edit obligations, comment on them and submit contracts for approval. Only General Counsel can approve or request changes. Business owners see only the contracts and obligations they own. The write queries are restricted server-side to named users: the legal queries to the General Counsel and one legal reviewer, and the approval decision queries to the General Counsel alone. Three workspace groups (Legal Reviewers, General Counsel and Business Owners) were created but have no members yet. In production, add members to those groups and move the query permissions onto them.

Self-Hosting ToolJet: Open Source, On-Premise and Air-Gapped Deployment

A Contract Obligations Review app often works with data that cannot leave your network, and ToolJet lets you run the whole platform on infrastructure you control instead of a vendor cloud. Both the community edition and the enterprise edition can be deployed on-premise, and air-gapped deployment is available for environments with no internet access.

Lease terms, counterparty details, and approval history sit inside a legal operations app, so keeping the runtime on company infrastructure gives security and IT reviewers a cleaner control boundary.

Self-Hosting ToolJet: Open Source, On-Premise and Air-Gapped Deployment

Deployment Options: Docker, Kubernetes and Major Clouds

ToolJet's self-hosting setup guides cover the common ways to run it in your own environment:

Docker Compose deployment: run ToolJet on a single server, with optional Terraform scripts to provision a VM on AWS, Azure or GCP first.
Kubernetes deployment: run ToolJet on your own cluster, with dedicated guides for EKS, GKE, AKS, Helm and OpenShift.
Your own PostgreSQL: ToolJet stores app definitions, encrypted data source credentials and user authentication data in a PostgreSQL database that you manage.

Open Source Core and Air-Gapped Enterprise Deployments

Open source community edition on GitHub: the ToolJet repository is released under the GNU Affero General Public License v3.0 (AGPL), so your team can inspect the code and self-host the community edition.
Air-gapped deployment: run ToolJet in fully isolated environments without external network access, listed on the ToolJet Enterprise plan.
ToolJet AI Enterprise: deploy the AI server image inside your own environment so AI requests are processed on your servers, which suits private-cloud and air-gapped setups.

Self-hosting keeps the Contract Obligations Review app, its data and its credentials inside the network and security boundary your team already governs, and a self-hosted community edition can be upgraded to the enterprise edition when you need enterprise features.

Enterprise Features for Your Contract Obligations Review App

A contract review app holds lease terms, counterparty details, and approval history. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. One workflow fires when a contract is submitted to General Counsel, posts the review request in Slack, emails the business owner through Gmail, and writes the decision back to clr_approval_log.

Final Takeaways

This build shows a legal operations app that keeps the contract PDF, obligation list, comments, and approval trail in one record while the register and calendar handle the wider portfolio. That matters because the generated result is a real ToolJet application, so the team keeps editing the same app instead of taking ownership of a codebase. The useful trade-off is the handoff between visual editing and deeper code when a clause jump or version rule needs it. The runtime carries the data and workflow pieces where supported, and that keeps the app editable as contracts and review rules change.

Try ToolJet MCP

Use your own contract data to build a contract obligations review app with ToolJet MCP, then request a ToolJet demo to map your review process.

FAQs

What is ToolJet MCP for this app?

ToolJet MCP is the build path that lets an agent create a ToolJet application from a written specification. For this app, the result keeps the PDF, obligations, comments, and approval history tied to the same contract record, so the review stays inside one workspace.

What makes this app useful for legal operations?

The app keeps the PDF and the extracted obligations side by side, so a reviewer can move from clause text to a comment without changing context. The calendar and register add deadline tracking, owner filtering, and portfolio search in the same workspace.

Can I reproduce the app from the prompt in this article?

Yes. The prompt in this article consolidates the full specification into one run, so you can recreate the app without rebuilding the requirements piece by piece. That gives you a single starting point you can reuse in your own build session.

Do I need to write code to change the app?

Not for the common changes. You can edit the layout, tables, filters, and review flow visually, then drop into code when a clause jump or approval rule needs it. That keeps the quick edits in the interface and the deeper logic in the right place.

Can I connect the app to existing contract data?

This build uses ToolJet DB. The same shape can map to an existing source if the contract, document, obligation, comment, and approval records line up cleanly, so you can bring your own records without changing the app structure.

What happens after the agent finishes?

You keep a real ToolJet application, not a code dump. The runtime keeps the data connections, workflow pieces, and role rules available where supported, so later changes update the app instead of restarting the build from scratch or rewriting the review flow.

Can several people work on the same app?

Yes. One person can adjust the review screen while another tunes the calendar or register, and the shared app structure keeps the contract record and approval trail aligned. That lets different people work in the same app without splitting the record.

Build Inventory and Pricing Command Centre with ToolJet MCP

Athulya R — Fri, 25 Sep 2026 12:05:16 +0000

Introduction

Here is how to construct an inventory and pricing command centre with ToolJet MCP for the merchandising team that keeps channel prices, stock risk and approvals in one place. Step by step, discover how to build an inventory and pricing command centre with ToolJet MCP for the merchandising group while coordinating repricing, alerts and purchase requests. Below, you will explore how to build an inventory and pricing command centre with ToolJet MCP for the merchandising team that manages pricing changes, stock shortages and product history. An agent generates the app, and what comes out is a structured ToolJet application, with data, queries and interface kept together for the team to run. The article shows the screen, the tables and the control flow so you can reproduce the result from the prompt in this article.

Catalogue: price, units this week and margin per channel, stock, cover versus lead time and the last price change

Alerts: stock-outs ranked by revenue lost over the lead time, pending price approvals and below-margin listings

Product: price history by channel, stock projection, channel prices and the price-change trail

Draft purchase request: quantity worked out from sell-through, lead time, case pack and MOQ, with the supplier email ready to review

What We're Building

The Catalogue page uses one dense row per product, so you scan price, sell-through, margin and stock context without opening extra screens. Reprice opens a modal that shows the live band, floor price and weekly impact, then asks for a reason before the change lands. Alerts orders stock-out risk by revenue at risk over supplier lead time, then surfaces a Draft PR action that calculates quantity and drafts the supplier note. The hidden product view keeps the deeper trail for a single SKU, including the price-change log and linked requests. The layout stays compact, muted and built for repeated review.

Dense product rows with channel pricing and stock context in one scan
A repricing modal with live band, floor price, margin preview and required reason
Ranked stock-out alerts that turn into drafted purchase requests
A hidden product view for price trails, stock movement and linked requests
Role-based access for merchandisers, category heads and finance

Build an Inventory and Pricing Command Centre with ToolJet MCP for Merchandising Teams

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The real build took several passes. The requirements are consolidated here into one prompt that could have been used from the start, so you can reproduce the app in a single shot.

Build a 3-page inventory and pricing command centre in ToolJet for the merchandising team of a consumer electronics brand selling through its own store, Amazon and two regional marketplaces. Use ToolJet DB tables prefixed mcc_: channels with fee percentages, categories with a minimum margin and a price band percentage, suppliers with lead time, MOQ and case pack, products with unit cost, stock on hand and reserved, channel prices with a stored band low and high, weekly sales per channel, weekly stock history, a price-change audit table, purchase requests and app roles. Seed about 20 realistic SKUs in USD.

Catalogue (home): one dense row per product with, for each channel, the price, units sold this week and margin after fees; stock on hand, reserved, available, cover versus supplier lead time, and the last price change. A Reprice row action opens a modal previewing the band, floor price, new margin and weekly margin impact, with a required one-line reason. Inside the band the price applies immediately; outside it is saved as pending for the category head. Every change writes old price, new price, who and why to the audit table.

Alerts: stock-out risks ranked by revenue lost over the lead time, not days of cover, each with a Draft PR action that works out the quantity (sell-through times lead time plus 28 days, minus available, rounded to whole cases, at least MOQ) and drafts the supplier email for a person to send. List listings below their category margin floor, and a pending-approval queue with margin impact where category heads approve or reject.

Product (hidden): price history by channel, stock history with a projection, channel prices, purchase requests and the price-change trail.

Roles: merchandisers change prices within the band, category heads approve out-of-band changes, finance sees everything and changes nothing. Enforce the band server-side, restrict every write query to the right groups and use a dense, muted Nordic design with native components.

How ToolJet MCP Builds the App

The agent works through the whole application, not the screen: the data model, the queries, the component tree and the wiring between them all land as one structured ToolJet application. Enterprise app building does not end at the interface, data connectivity, workflows, permissions, deployment and ongoing change are the rest of the job, and the generated app sits on a runtime that carries those where supported instead of handing the team a codebase to operate themselves. The path stays open: AI generation, then visual editing, then code where a case needs it.

The One Thing That Broke

The first catalogue and alerts tables clipped on a laptop because the combined columns were wider than the canvas. Tightening the row density and simplifying the table layout fixed the fit, and the app rendered cleanly after that.

Data Created

The app ended up with ten tables in three groups. mcc_products, mcc_channel_prices, mcc_categories, mcc_channels and mcc_suppliers hold the merchandising reference data, mcc_sales_weekly and mcc_stock_history capture demand and stock movement, and mcc_price_changes, mcc_purchase_requests and mcc_app_roles track change history, requests and access.

Page	Components	What they cover
Catalogue	11	dense product table and the reprice modal
Alerts	16	stock-out ranking, approvals queue, low-margin list and the PR modal
Product	13	price and stock history, channel prices and the audit trail

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	10
Queries	23
Components	40
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

Industries That Run This

Consumer electronics and appliance brands, direct-to-consumer retailers selling on Amazon and regional marketplaces, fashion and footwear merchandising teams, home goods and personal care brands, and any omnichannel seller that prices the same catalogue differently per channel while buying stock from suppliers with long lead times.

Who Gets Access To The Built App

As built, three workspace groups gate the writes. Merch - Merchandisers and Merch - Category Heads can change prices and draft purchase requests; only Merch - Category Heads can approve or reject out-of-band changes; Merch - Finance and everyone else can open every page but no write query runs for them. The price band is also enforced on the server by the write query itself. The groups were created empty, so people still have to be added to them, and the app's role table only drives what the interface enables.

Role-Based Access Control in ToolJet

A Merch Command Centre app is only ready for a real team when every person can see and change exactly what their job needs, and nothing more. ToolJet handles this with role-based access control (RBAC) at two levels: platform-level permissions decide who can reach a workspace resource at all, and app-level permissions decide what each user can open, run and see inside one app. Both are enforced by the ToolJet server, not by hiding controls in the browser.

ToolJet role-based access control: platform-level and app-level permission layers

App-Level Permissions: Pages, Queries and Components

Inside the app builder, ToolJet dynamic access rules restrict individual parts of an app to chosen users or groups, so one app can serve several roles without a copy per team.

Page permissions: decide who can open a page, such as an approvals queue or an admin screen, while everyone else keeps the pages they need.
Query permissions: decide who can run a query. This is the layer that protects the data: a read-only user cannot trigger a write query even if they find the button.
Component permissions: decide who sees and uses a component such as a button, form or modal, so a viewer gets a clean screen instead of controls they cannot use.
Row-level security: filters which records each user gets back from a query, so a manager sees their own region and not the whole table.

Query permissions in the builder: the five write queries are locked to the merchandiser and category head groups

Platform-Level Permissions: Roles, Custom Groups and Access Rules

At the workspace level, ToolJet decides who can reach an app, a data source or a workflow before any app-level rule applies.

User roles: every member has a base role, Admin, Builder or End user, which sets what they can do in the workspace.
Custom groups: group people by team, such as finance or regional managers, and grant permissions once to the group instead of person by person.
Granular access rules: for each group, choose which apps it can edit or only view, whether an app is hidden from the dashboard and which environments it can open, which data sources it can configure or build with, and which workflows, modules and folders it can reach.
Workspace permissions: group-level switches for creating and deleting apps, managing workspace constants, working with ToolJet Database and organising folders.

Custom groups in workspace settings, each with granular view access to the Merch Command Centre app

Together, the two layers let one Merch Command Centre app go live for the whole team: platform permissions decide who gets in, and app permissions decide what each role can do once inside. ToolJet MCP can apply these rules while it builds, so access control ships with the first version of the app instead of arriving as a retrofit. Dynamic access rules are part of the ToolJet Enterprise plan.

Enterprise Features for Your Inventory and Pricing Command Centre

A merchandising app handles product costs, price-change history, and supplier lead times. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. One workflow fires when a category head approves an out-of-band price change, posts a Slack message with the SKU and new price, emails the merchandiser through Gmail, and writes the decision back to mcc_price_changes.

Final Takeaways

This build shows that an agent can assemble a working merchandising application, not just a layout, by tying product rows, repricing, stock risk and purchase request drafts into one app. The structured ToolJet application matters because the output stays inside a runtime you continue to edit, instead of becoming a codebase you now have to own end to end. Visual edits cover most changes, code handles the sharper rules, and the data, workflow and access layers stay in step as the app changes over time.

Try ToolJet MCP

Build your own merchandising command centre with ToolJet MCP, then request a ToolJet demo for your product and stock data.

FAQs

What does the ToolJet agent build path do?

It turns a written requirement into a working app inside ToolJet, with pages, queries, data tables and access rules connected as one system. In this build, that means merchandising data, repricing logic and stock alerts live together in one application.

What does the catalogue page show in Merch Command Centre?

The catalogue page gives you one row per product with channel pricing, units sold, margin and stock context in a single scan. From that row, you open repricing, see the live band and reason field, and write a change to the audit trail.

Can I use my own merchandising data for this app?

Yes. The app is shaped around product, channel price, sales, stock, supplier, request and role records, so your own data can fit if the same business fields exist. The prompt in this article gives the same structure the build expects.

Do I need to write code for this app?

You do not need code for the core flow. The visual app covers the tables, screens and approvals, and you only drop into code when a calculation or rule needs a tighter expression.

What happens to the app after the agent finishes?

The agent leaves you with a structured ToolJet application, not a screen mockup or a code drop. ToolJet keeps the app on its runtime, so the data, queries, workflows and access rules stay attached as the requirements change.

How is this different from starting with generated code?

A generated codebase hands you files first and integration work later. This build starts with the app structure already in place, so the business rules, data tables and approvals are connected from the start.

Can several people work on the same app at once?

Yes. Role-based access lets merchandisers, category heads and finance users share the same application without sharing the same write paths. In this build, price edits and approvals follow different permissions, so each group sees the actions it owns.

Build an Invoice Verification App With ToolJet MCP

Athulya R — Thu, 24 Sep 2026 12:07:14 +0000

Introduction

Learn how to build an invoice verification app with ToolJet MCP for an accounts payable team that handles scanned supplier bills. The app keeps the scan, extracted values, duplicate checks, match results, routing reason, and approval state on one record so clerks and approvers work from the same source of truth. The output is a structured ToolJet application, not a screen or a code drop, and the team keeps running it as the invoice flow changes. In this article you see the finished app, get the prompt, and see how the build hangs together around real invoice work.

Capture & Review: the Boral Concrete scan beside what Textract read, the routing preview, and a $530 over-tolerance line in the three-way match

Approval Queue: waiting invoices with who each is routed to, its age and three-way match result, and the review panel below

Monthly Summary: September KPIs, spend by supplier, the six-month trend and the supplier breakdown

What We're Building

The main review page puts the original scan beside editable fields so you can check the source without leaving the record. Low-confidence reads stand out immediately, duplicate invoices trigger a warning, and each line shows ordered, received, and invoiced quantities with the variance that needs a clerk decision. When a variance is within tolerance, the clerk records the reason and moves on; when it is not, the invoice stays on the path that routing rules assign. The approval page then compresses the case into a queue, the scan, the routing reason, the match view, and the action buttons. The monthly page gives the same record a supplier view through summary tiles, a spend chart, a trend line, and a breakdown table.

Capture supplier invoices from scans and keep the original image beside the editable fields
Highlight low-confidence reads, duplicate invoice checks, and line-level match gaps before routing
Compare ordered, received, and invoiced quantities with a logged clerk tolerance decision
Route each invoice with a stored reason into an approval queue scoped by role
Review spend by supplier with monthly summary tiles, trends, and a breakdown table

Build an Invoice Verification App With ToolJet MCP for AP Review

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The real build took several passes, and the requirements are consolidated into one prompt that could have been used from the start. You can reproduce the same invoice verification app in a single shot from the prompt below, without reconstructing the earlier iterations.

Build a 3-page invoice verification app in ToolJet for the accounts payable team of a Melbourne construction contractor handling about 900 scanned supplier invoices a month. Use only native components, dense enterprise layouts, slightly larger fonts, and a muted Nordic theme: linen and off-white surfaces, slate-blue primary, sage and ochre accents.

Store data in an existing PostgreSQL datasource in ivp_ tables: suppliers, purchase orders, PO lines, goods receipts, invoices, invoice lines, tolerance log, app roles and settings. Put the three-way match and routing logic in SQL views. Read invoices with Amazon Textract (forms and tables) and store uploads in Amazon S3.

Roles come from the signed-in user's email: AP clerks capture and correct, site managers see only invoices routed to them, the finance controller sees everything.

Capture & Review: an Upload invoice button, the original scan on the left and an editable form on the right, each scrolling independently. Show supplier, invoice number, date, PO, subtotal, GST, total and line items, and flag any value read under 90% confidence. Warn and block routing when the same supplier, invoice number and amount was seen before. Show ordered, received and invoiced quantities per line side by side, highlight disagreements with the difference in units and dollars, and let a clerk accept a variance within 2% of the PO line or $50, whichever is smaller, logging who accepted it, the amount and the reason.

Routing, stored on the invoice with its reason: no matching PO goes to an exceptions queue at any value; an unresolved variance or a total of $10,000 or more goes to the finance controller; otherwise it goes to the site manager on the PO.

Approval Queue: KPI tiles, a queue table and a review panel with the scan, the routing reason, the match and approve, reject or send-back actions. Monthly Summary: KPI tiles, spend by supplier, a six-month trend and a supplier breakdown table.

How ToolJet MCP Builds the App

ToolJet MCP takes the requirements as one application brief and works through the whole invoice app, not just the visible form: the data model, queries, pages, components, and the wiring between them land as one structured ToolJet application. That matters because invoice verification does not end at the interface, the runtime also has to carry data connectivity, workflows, permissions, deployment, and ongoing change where supported, instead of leaving you with a codebase to operate yourself. The path stays open, so you can keep moving from AI generation to visual editing and then into code when a case needs it.

The One Thing That Broke

The Boral invoice briefly showed Reece supplier data, so the captured fields looked wrong on screen. The editor-mode query run endpoint had persisted a Reece image as the Textract query document, which meant later reads used the wrong scan. Resetting that document link fixed the issue.

Data Created

The app ended up with nine tables in three groups. ivp_suppliers, ivp_purchase_orders, ivp_po_lines, and ivp_goods_receipts hold the purchasing trail, ivp_invoices, ivp_invoice_lines, and ivp_tolerance_log hold capture and variance handling, and ivp_app_roles plus ivp_settings control access and thresholds.

Page	Components	What they cover
Capture & Review	36	routing banner, upload and action toolbar, scan beside the editable form, checks strip, line items, three-way match and tolerance log
Approval Queue	16	queue KPIs, queue table with Review, scan, routing reason, facts, match table and approve/reject/back actions
Monthly Summary	10	month picker, six KPI tiles, spend-by-supplier and six-month charts, supplier breakdown table

What Got Generated

Metric	Result
Pages	3
PostgreSQL tables	9
Queries	33
Components	62
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

Industries That Run This

Construction and civil contractors, facilities and property maintenance firms, manufacturers, wholesalers and distributors, and any accounts payable team that pays suppliers against purchase orders and goods receipts, especially where invoices still arrive as scans, PDFs and phone photos.

Who Gets Access To The Built App

As built, access is decided by the signed-in user's email in the app's own roles table and enforced in every query. AP clerks upload, correct and route invoices and accept small variances within tolerance. Site managers see and decide only the invoices routed to them from their purchase orders. The finance controller sees every queue, approves high-value and escalated invoices, and works the exceptions queue with AP. The build did not create ToolJet user groups or page permissions; in production, add groups for these three roles and restrict pages to match.

Enterprise Features for Your Invoice Verification App

An invoice verification app handles supplier invoices, payment totals, and approval reasons. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows an invoice verification app that pulls scan data, catches duplicates, compares ordered, received, and invoiced quantities, and routes each record with a stored reason. The result is a structured ToolJet application on a mature runtime, so you keep editing the same app after generation instead of owning a handoff to code. That matters because visual editing, code where needed, data connectivity, workflow logic, and access rules where supported all stay attached to one application as the process changes. The article shows the shape of a business app, not just a page.

Three to four builds per model across four-page apps. 1 credit = 1 cent. Credits and time are estimates only and will vary with the complexity of what you ask for. This measures cost and speed only, not how complete or polished the result is.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own invoice verification app with ToolJet MCP around your existing invoices, then request a ToolJet demo.

FAQs

What does ToolJet MCP do for an invoice verification app?

ToolJet MCP takes the app requirements and turns them into a structured ToolJet application with pages, queries, components, and wiring. For this build, that means the invoice scan, duplicate check, match logic, routing reason, approval queue, and monthly review stay in one app.

What does the capture screen do with a scanned invoice?

The Capture and Review page shows the scan beside editable fields so you can correct Textract output while the source image stays visible. Low-confidence values stand out, duplicate invoices raise a warning, and line items show the three-way match context.

Can you reproduce the build from the prompt in this article?

Yes, the prompt in this article is the single build spec the article uses for reproduction. You can paste it into the agent flow and get the same three-page invoice verification workflow without reconstructing the earlier iteration history.

Do you need to write code to use this app?

No code is required to get the first version of the app. The generated app is still editable, so you can adjust the layout, routing rules, and record handling visually, then drop into code when a case calls for it.

What happens to the app after the agent finishes?

The output is a structured ToolJet application, not a throwaway screen or a code bundle. That means the runtime keeps the data connections, workflow logic, and app shape together, and you keep iterating on the same record as the process changes.

Can this app use existing PostgreSQL, S3, and Textract data?

Yes, this build stores invoice data in an existing PostgreSQL datasource, keeps uploads in Amazon S3, and reads documents with Amazon Textract. The app then uses those sources for capture, matching, routing, and monthly review.

Can several people keep working on the same app?

Yes, the app is a shared ToolJet project, so more than one person can continue the same build instead of creating separate copies. That keeps the invoice flow, tables, and queries aligned while different people update the same application.

Build A Warehouse Layout Planner With ToolJet MCP

Athulya R — Wed, 23 Sep 2026 16:58:57 +0000

Introduction

Build a warehouse layout planner with ToolJet MCP when your distribution centre team needs to turn floor plans into a live operating view instead of a marked-up drawing. The app was generated from the prompt below as a structured ToolJet application, with data, queries, and interface held together as one system. The result gives the team a place to compare saved layouts, review clear rule checks, and keep rack placement aligned with day-to-day operations. You can use the walkthrough to see the finished planner and rebuild the same planning flow on your own site.

Layout Editor: Zone C Forward Pick loaded, a dock door selected in the inspector, and a live overlap warning

Compare Layouts: Zone C Forward Pick vs Zone D Wide Aisle. Picker travel 261,092 to 391,322 per day (+50%), pick faces 40 to 36, narrowest aisle 3.5 m to 4.0 m

What We're Building

The editor centers on one canvas with a saved-layout row above it and a selected-element inspector inside the canvas. You add racks, dock doors, safety zones, and fire exits from the toolbar, then drag or resize them on the grid while the live checks repaint problem shapes and name the broken rule under the floor plan. The comparison page keeps two saved layouts read-only, shows them side by side with a shared legend, and adds scorecards for pick faces, aisle clearance, and picker travel so you can read the trade-off before saving a change. When the selected shape changes, the inspector updates in the same panel, so the editor never loses context.

Drag racks, dock doors, safety zones, and fire exits onto a snap-grid canvas
Resize selected shapes from a corner handle and keep the same live rule checks
See broken rules named under the canvas as you edit
Compare two saved layouts side by side with pick faces, aisle clearance, and travel deltas
Save layouts and SKU assignments together so the plan reloads with the same mapping

Build A Warehouse Layout Planner With ToolJet MCP, Then Review The Floor Plan

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes before the floor plan, comparison view, and saved-layout flow all lined up cleanly. The requirements are consolidated into one prompt below so you can reproduce the app in a single shot without reconstructing the iteration history.

Build a polished internal app called Warehouse Layout Planner in ToolJet.

Keep it to two pages: Layout Editor and Compare Layouts. Layout Editor shows the floor plan, a saved-layout row, stat tiles for pick faces and rules broken, a canvas toolbar, live rule checks, and a selected-shape inspector. Compare Layouts shows two saved plans side by side, a shared legend, and a clear comparison of aisle clearance, pick faces, and picker travel.

Use the same visual language for the scorecards and the layout previews so the page reads like one planning surface. Design it as a clean technical planning app: cream background, charcoal text, thin lines, muted fills, compact spacing, and status colour used only where it helps.

Use six related tables: warehouse_layouts, layout_shapes, skus, pick_face_assignments, warehouse_rules, and shape_legend. The plan should keep saved geometry, SKU assignments, rules, and canvas styling separate, so the app can calculate readiness and comparison results from stored data instead of screen state.

Use only native ToolJet components everywhere except the floor-plan canvas, which is a single CustomComponent. The editor must let users place racks, dock doors, safety zones, and fire exits on a 1 m grid, resize shapes, assign SKUs to racks, and save named layouts. The full 90 m by 55 m floor should fit the panel without scrolling, labels on thin shapes should move above or beside the shape, and critical rules must show live.

How ToolJet MCP Builds the App

MCP works through the whole application, not the screen: the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. In this build, that means the editor, the compare view, the live rule feedback, and the saved-layout flow all arrive together instead of as a disconnected screen. Enterprise app building does not stop at the interface, so data connectivity, workflows, access control, deployment, and ongoing change sit on the runtime where supported, rather than handing you a codebase to operate yourself. The path stays open after generation, so you can keep moving between AI generation, visual editing, and code when a specific part of the planner needs it.

The One Thing That Broke

One save path issue showed up when a rack's SKU disappeared after you edited the canvas, because the app was reading stale state. The fix keeps the shape ids and assignments together during save, so the same rack-to-SKU mapping comes back after reload.

Data Created

The app ended up with six tables in three groups. warehouse_layouts and layout_shapes hold the saved plans and their geometry, skus and pick_face_assignments connect products to rack faces, and warehouse_rules and shape_legend hold the planning rules and canvas styling. Together they separate the saved plan, the product mapping, and the rule set, which keeps the editor and the compare view reading from the same stored model. The compare page can then read the same tables without depending on a pasted drawing.

Page	Components	What they cover
Layout Editor	13	saved-layout row, stat tiles, SVG floor-plan canvas with built-in toolbar and inspector, rules-broken panel
Compare Layouts	25	two layout pickers, side-by-side plans with scorecard, pick-face and travel tiles, narrow-aisle and SKU travel tables

What Got Generated

Metric	Result
Pages	2
ToolJet DB tables	6
Queries	19
Components	38
Code files to maintain	0
Repair cycles	1

Industries That Run This

Distribution centres, third-party logistics warehouses, retail and e-commerce fulfilment operations, and manufacturers that run their own finished-goods or parts stores: any site that re-slots racks and pick faces and has to keep forklift aisles, fire exits and safety zones clear while doing it.

Who Gets Access To The Built App

Recommended setup, not yet configured in this build: warehouse managers and continuous improvement engineers should be able to create, edit and save layouts, and shift supervisors should be able to open and compare layouts without changing anything. The build did not create these groups. To enforce the split, create two workspace groups in ToolJet (an editor group and a view-only group), add the right people to each, and set the app's permissions so only the editor group can edit it. Until that is done, anyone with access to the app can change layouts.

Enterprise Features for Your Warehouse Layout Planner

A warehouse layout planner handles floor plans, SKU placements, and safety rules. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows that one prompt can produce a warehouse layout planner with saved layouts, live geometry checks, and a comparison view that keeps the trade-off visible. The result is a structured ToolJet application, so the team keeps editing the same app after generation instead of owning a code drop and a separate operating burden. That matters because visual editing, code where the case needs it, and the runtime's data and workflow layer can live together as the floor plan changes. The app stays tied to the real planning model, which keeps governance and long-term maintenance inside one application.

Cost and Speed by Model

You can easily build a 4-page app with ToolJet MCP for as little as $0.17 with a lean model (Luna medium), or pay more for the latest flagship reasoning (Sol) if that's what you're after. The cost is your call, not a floor we set for you.

Model	Credits	Minutes	Notes
Astra	290 to 550	13 to 16	The most polished pages, when cost matters less
Sol (Recommended)	300 to 650	14 to 22	The best balance of quality and cost for most apps
Terra	85 to 210	5 to 12	The fastest, and best kept to smaller apps
Luna max	35 to 55	33 to 62	The most complete Luna, and by far the slowest
Luna high	25 to 50	22 to 41	Mid-effort Luna, between medium and max
Luna medium	10 to 30	14 to 20	A quick first draft or a small tool

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build a warehouse layout planner with ToolJet MCP, then request a ToolJet demo to map it onto your site.

FAQs

How do I build a warehouse layout planner with ToolJet MCP from the prompt here?

Use the prompt in this article to generate the planner as one ToolJet app with saved layouts, live rule checks, and a comparison view. The same app keeps geometry, SKU assignments, and layout review together.

What do I get on the layout editor page?

The layout editor gives you a snap-grid canvas, a saved-layout row, and an inspector for the selected shape. You place racks, dock doors, safety zones, and fire exits, then resize them while the rule warning updates in place.

How do I compare two warehouse layouts?

The comparison page shows two saved layouts side by side with a shared legend. You read pick faces, aisle clearance, and picker travel so the difference between plans is easy to judge before you save.

Do I need code to edit racks or labels after generation?

You can move, resize, relabel, and reassign shapes in the editor without leaving the app. When a case needs it, the same app still leaves room to drop into code for custom logic.

What happens to the app after the agent finishes?

The generated result is a real ToolJet application on the runtime, so the team keeps editing the same app after generation. Data connections, workflows, and access control are handled at the platform layer where supported, which keeps the planner as an application instead of a one-off code handoff.

Can I use my own warehouse data?

Yes, the planner is built around saved layouts, shape geometry, SKU records, and pick-face assignments. You can map those pieces to the data source your team already uses and keep the same interaction model.

Can several people work on the same planner?

Yes, the planner can be shared as one app, so teammates work from the same saved layouts and review changes as the floor plan changes. That keeps the latest plan in one place instead of spreading edits across copies.

Build Storm Outage Control Tower with ToolJet MCP

Athulya R — Mon, 21 Sep 2026 13:27:27 +0000

Introduction

Build storm outage control tower with ToolJet MCP when a utility control room needs a single app for storm response. The app that comes out is a structured ToolJet application, with data, queries, and interface kept together so the team keeps running it after generation. Controllers use the same app to keep operational decisions and public communication aligned while the storm is active. You get a control-room workflow that turns live utility data into one place the team can keep using. This walkthrough shows the app, the prompt, and the build shape you can reproduce.

Live Map: ranked outages, live map, and crew/ETA assignment panel

Crew View: each crew's current job and queue

Public Messages: auto-generated status text with Duty Manager approval

What We're Building

The main view pairs a ranked outage table with the map, so the controller moves from priority score to geography without changing context. Selecting a row opens the outage detail panel, where customer counts, linked priority sites, the assigned crew, and the restoration ETA stay visible while the controller updates the assignment. If the ETA slips into the warning window, the panel asks for a revised time and a short reason, and the original estimate remains visible for comparison. The crew view filters to current and queued jobs, and the public messages page turns the current ETA into approval-ready text.

Rank outages with a visible priority score built from customers off, priority sites, outage age, and vulnerable customers
Move from the map into crew assignment and ETA edits in one detail panel
Keep the original ETA visible when a revised time and reason are required
Show each field crew only its own queued and active work
Generate public outage text from the controller's ETA and gate publishing behind Duty Manager approval

Build storm outage control tower with ToolJet MCP across the live map, crew view, and public messages

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes while the layout and data model settled into place. The requirements are consolidated into one prompt you can use from the start to reproduce the app in a single shot.

Build a control-room app called Storm Outage Control Tower in ToolJet for an electricity distribution utility.

Keep three pages: Live Map, which ranks outages, shows them on a map, and lets controllers assign crews and set restoration ETAs; Crew View, which shows each crew's current work and next jobs; and Public Messages, which turns the controller's ETA into a public status update that must pass Duty Manager approval before publishing.

Use a dark control-room look with strong status colours, very large customer-off numbers, and only native ToolJet components. Keep the outage table narrow and put navigation on top.

Use PostgreSQL and four related tables: om_crews, om_outages, om_priority_sites, and om_public_messages. Rank outages with a defensible score built from customers off, priority sites on the feeder, outage age, and vulnerable customers.

When an ETA is already late or close to late, require a revised time and a short reason, while keeping the original ETA visible. For restored outages, show reported time, crew assigned time, restored time, and customer-minutes lost. Public messages must always be generated from the current ETA, never typed separately, and if the ETA changes after submission the message must be marked stale and resubmitted. Field crew users only see their own assignment, while controllers can see every crew.

How ToolJet MCP Builds the App

ToolJet MCP works through the outage model, pages, components, queries, and the wiring between them, then leaves you with one structured ToolJet application inside ToolJet rather than a codebase to host yourself. Enterprise app building does not stop at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change are part of the job, and the generated app sits on a runtime that carries those where supported. The path stays open, so you can move from AI generation to visual editing and then into code when a case needs it.

The One Thing That Broke

One outage detail panel showed the wrong row as selected after a table click. The cause was a stale default selection value that made the row state look truthy after the active row changed, and clearing that default fixed the panel so the detail view matched the clicked outage again.

Data Created

The app ended up with four tables. om_crews stores the crew roster and current assignment state, om_outages holds outage location, status, ETAs, and customer impact, om_priority_sites records critical sites on a feeder, and om_public_messages keeps each outage's public message and approval state.

Page	Components	What they cover
Live Map	12	Ranked outage list, live map with outage/crew markers, and a detail panel for crew assignment and ETA management
Crew View	2	Each crew's current job and queue, filtered server-side to the logged-in crew
Public Messages	9	Public status message per outage, generated from the live ETA, with Duty Manager approval before publishing

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	4
Queries	11
Components	23
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

Industries That Run This

Electricity distribution network operators and other utility control rooms (water, gas) running storm or multi-outage response, plus telecoms and other regulated infrastructure operators who owe customers a defensible restoration-priority order and a regulator-facing post-event summary.

Who Gets Access To The Built App

Controllers get full write access - assigning crews, setting and revising ETAs. Field crews only see their own current and queued jobs, enforced server-side by matching the logged-in user's email against the crew record, not by a client-side filter. Public messages require a Duty Manager's explicit approval, recorded by name, before they can be published - controllers can draft and submit but not publish directly.

Enterprise Features for Your Storm Outage Control Tower

Outage locations, crew assignments, and public ETA text move through this app. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. When a controller submits a public message for approval, a workflow posts the update to Slack, emails the duty manager through Gmail, and writes the approval state back to om_public_messages.

Final Takeaways

This build shows a storm outage control tower that ranks outages, ties map context to crew dispatch, and keeps public messages locked to the controller's current ETA. The output is a structured ToolJet application, so once generation finishes you keep working in the same app instead of inheriting a disposable screen or a separate codebase. That matters because the visual editor covers the routine changes, code stays available for edge cases, and the runtime keeps the data, workflows, and governance in one place where supported, which is the shape you want when the process changes during a storm.

Cost and Speed by Model

Model	Credits	Minutes	Notes
Astra	290 to 550	13 to 16	The most polished pages, when cost matters less
Sol (Recommended)	300 to 650	14 to 22	The best balance of quality and cost for most apps
Terra	85 to 210	5 to 12	The fastest, and best kept to smaller apps
Luna max	35 to 55	33 to 62	The most complete Luna, and by far the slowest
Luna high	25 to 50	22 to 41	Mid-effort Luna, between medium and max
Luna medium	10 to 30	14 to 20	A quick first draft or a small tool

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build storm outage control tower with ToolJet MCP from your own outage data, then request a ToolJet demo.

FAQs

What does the prompt in this article produce?

The prompt in this article lets you build storm outage control tower with ToolJet MCP as a structured ToolJet application, not a loose screen mockup. The outage model, crew dispatch, and public message flow stay connected to the same data and page logic, so the app keeps its shape after generation.

What do the three pages do?

The live map ranks outages and shows where they sit, the crew view shows current and queued work for each team, and the public messages page turns the current ETA into a publishable update. The three views share the same outage records, so a controller does not re-enter the same facts.

Do you need to write code to adapt the app?

No code is required for the common edits in this build, because the layout, data wiring, and message flow are already in the app. You can change the map, tables, and text in the visual editor, then drop into code only when a special case needs it, which keeps the routine changes fast to adjust.

Can you use your own PostgreSQL outage data?

Yes, the app is built on PostgreSQL, so you can point it at your own outage records and keep the same control-room flow. The ranked view, crew assignment, and public messages page all work from the same source of truth, which makes the existing database the starting point instead of a rewrite.

What happens to the app after the agent finishes?

You keep a structured ToolJet application, and the runtime keeps carrying the data and workflow pieces where supported. Later changes happen in the same app instead of handing your team a code bundle to own and reassemble again.

How do you reproduce this build from the prompt?

Use the consolidated prompt in this article to describe the three pages, the four tables, and the rule that public messages always follow the controller's ETA. The prompt lets you start from the same requirements and get the same control-room shape in one pass.

Can several people work on the same app?

Yes, the app stays a shared ToolJet artifact, so teams can work against one outage model instead of copying exports around. That helps a controller, a builder, and a reviewer stay aligned when the table, map, or message flow changes.

Build a Dispatch Command Centre with ToolJet MCP

Athulya R — Fri, 18 Sep 2026 13:59:37 +0000

Introduction

You build a dispatch command centre with ToolJet MCP for a regional broadband operator when technician locations, open jobs, and outage zones all change at once. The result is a structured ToolJet application, with data, queries, and interface working together, so dispatchers keep operating from the same place instead of juggling separate views. This article shows the app that came out of the build, then gives you the prompt below so you can reproduce the same structure in your own environment. You get a two-page workflow that keeps live routing and end-of-day review inside one app.

Dispatch Command Centre — live map, breach-risk job queue, and active outages

End of Day Summary — completed vs. missed jobs and the by-region hot-areas table

What We're Building

The map does the real work on page one, with technician pins, job pins, and outage shading sharing one view. A queue on the left sorts unassigned jobs by urgency, and each suggestion shows why a technician rises to the top before you act. Clicking a job or technician opens the relevant detail panel, then the reassignment flow shows the overbooked minutes, skill match, and detour impact before anything is saved. Page two switches to a read-only summary, and the branded header keeps the title, subtitle, live counter, and page link visible across both views.

Live map with technician positions, open jobs, and outage shading
Urgency queue that ranks unassigned work and explains technician suggestions
Reassignment preview that checks skill match, capacity impact, and route detour before save
End of Day Summary page with regional performance and hot-area readouts
Role-scoped views for dispatchers, technicians, and regional managers

Build a Dispatch Command Centre with ToolJet MCP for Live Routing

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The real build took several passes, and the requirements are now consolidated into one prompt you can use from the start. That gives you a single-shot reference for reproducing the same app instead of reconstructing the work from the iteration history.

Build a polished internal app called Dispatch Command Centre for a regional broadband provider in Ontario, using Supabase Postgres.

Keep it to two pages: Dispatch Command Centre, showing technician positions, open jobs, outage overlays, urgency-ranked unassigned work, technician suggestions, and the reassignment flow. End of Day Summary, showing completed, missed, total, and on-time results, plus regional breakdowns and hot areas.

Design it as a muted warm enterprise operations app with soft shadows, rounded corners, warm orange accents, cozy spacing, and a friendly hierarchy. Support light and dark mode with distinct color tokens for each, and replace the default page chrome with a custom branded header band that includes an eyebrow label, title, subtitle, live open-jobs counter, and a link to the summary page.

Use five related tables: technicians, jobs, outage_areas, staff, and reassignment_log. Resolve the signed-in user's role and region from staff on page load, then scope every query and list to that role. Dispatchers can reassign work, technicians see only their own day as read-only, and regional managers see everything read-only.

A reassignment confirmation must show the overbooked minutes, skill match, and detour minutes before save. On confirm, update the assigned technician and write the audit row. The prompt also seeds about 80 technicians, 150 jobs, and a handful of active outage areas across five Ontario regions.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries, and the wiring between them land together as one structured ToolJet app. That matters here because dispatch software does not stop at the interface, it also needs data connectivity, workflows, permissions, deployment, and ongoing change, and the generated app sits on a runtime that carries those where supported instead of leaving you with a codebase to operate yourself. The path stays open after generation, because you can keep editing visually and drop into code when a specific detail calls for it.

The One Thing That Broke

The map looked finished, but the technician and job markers never appeared, which made the live view feel empty even though the data was present. A marker ID mismatch in the Map component caused the problem, and fixing that wiring restored every pin.

Data Created

The app ended up with five tables. staff maps login email to role, region, and technician assignment, technicians stores each field technician and their shift capacity, jobs tracks service work and assignment, outage_areas marks active regional outage zones, and reassignment_log keeps the audit trail for every change. The live map, the urgency queue, and the summary page all read from those tables, while the reassignment flow writes back to jobs and records the decision in reassignment_log.

Page	Components	What they cover
Dispatch Command Centre	39	Live map, breach-risk job queue, active outages, and the reassignment flow with consequence preview
End of Day Summary	14	Completed/missed/on-time stats and a by-region hot-areas table

What Got Generated

Metric	Result
Pages	2
ToolJet DB tables	5
Queries	17
Components	53
Code files to maintain	0
Repair cycles	1
Final validation	2 errors

Industries That Run This

Regional broadband and telecom providers, utilities, field-service and home-repair networks, HVAC and plumbing dispatch operations, and any business that has to coordinate a distributed field workforce against time-boxed customer commitments.

Who Gets Access To The Built App

Dispatchers can reassign jobs and see their own region (or every region, if unscoped). Technicians have read-only access to their own day's jobs. Regional managers have read-only access across every region. Access is enforced at the application/query level against a staff table keyed by login email, not as a hard database-level security boundary.

Enterprise Features for Your Dispatch Command Centre

A dispatch command centre handles technician locations, customer job details, and outage zones. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. One workflow fires when a reassignment is confirmed, sends a Slack message to dispatch, sends a Gmail message to the technician, and writes the decision back to reassignment_log.

Final Takeaways

This build shows a dispatcher can move from a single prompt to a live map, urgency sorting, pre-save consequence checks, and a read-only summary page tied to real regional data. The important part is not the screen alone, it is the structured ToolJet application behind it, because the result stays editable inside the same runtime instead of becoming a code handoff you must reassemble later. That is where visual editing, code where needed, and the runtime's data and workflow pieces fit together with role scoping and audit history, so the app can keep changing as dispatch rules change.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build a dispatch command centre with ToolJet MCP for your own field data, then request a ToolJet demo.

FAQs

What does Dispatch Command Centre show on first load?

It opens on the map, the urgent job queue, and the outage overlay, with the header showing the current open-work count and a link to the summary page. Clicking a technician or job opens the details needed to route work without leaving the page.

How do I reproduce this app with ToolJet MCP?

Use the prompt in this article as the full spec and let ToolJet MCP build the structure in one pass. The goal is the same two-page dispatch app, with the tables, role scoping, map, preview modal, and summary page already defined.

Do I need to write custom code for the core dispatch flow?

Not for the core flow. The prompt drives the data model, page layout, role scoping, map behavior, preview modal, and summary page, and you only drop into code when a specific edge case needs it.

What happens to the app after the agent finishes?

You keep a ToolJet application, not a disposable draft. The runtime carries the data connections, workflows, permissions, and maintenance path where supported, so changes stay inside the same app as dispatch rules change.

Can I point the app at my own Postgres data?

Yes, the build is centered on a Postgres datasource. Your technicians, jobs, outage areas, and staff tables can supply the live data while the prompt in this article defines the app shape.

How are reassignment warnings calculated?

The preview compares the target technician's remaining capacity, required skills, and added route time before the reassignment is saved. The dispatcher sees the consequence values first, then decides whether to proceed.

Can dispatchers, technicians, and managers use the same app?

Yes. The app reads the signed-in user's role and region from staff, then scopes each page so dispatchers can reassign, technicians stay read-only, and regional managers see the full picture.

Build a Device Register with ToolJet MCP

Athulya R — Thu, 17 Sep 2026 14:46:48 +0000

Introduction

You build a device register with ToolJet MCP when a multi-academy trust needs one place to issue, return, move, and write off laptops and tablets across 11 schools instead of chasing per-school spreadsheets. The app in this article turns that brief into a structured ToolJet application, with data, queries, and interface kept together so the team keeps running the register rather than juggling a screen and a separate code export. The result gives device coordinators and finance staff one live place to manage stock, history, and the handovers that happen every term.
You can easily build a 4-page app with ToolJet MCP for as little as $0.17 with a lean model (Luna medium), or pay more for the latest flagship reasoning (Sol) if that's what you're after. The cost is your call, not a floor we set for you.

Scan & Record: look up a device by asset tag and issue, return, move or write it off

Register: every device across all 11 schools, searchable by school and status

Summary: per-school breakdown chart and the damage-charge approval queue

What We're Building

The home page centres on a scan panel and a device detail card, so the user starts from one asset tag and moves straight into action. A camera scan or manual entry fills the card with school, holder, status, and condition, while a recent-activity feed keeps the last scans and actions visible during the session. Bulk issue mode changes the flow for a class rollout: pick the class, scan devices one by one against a running count, and use Undo to roll back the last scan when the wrong device is entered. Opening a device in the Register page brings up the full movement history in a modal, and the Summary page pulls the counts and damage-charge queue into one view for finance.

Camera scan with manual asset-tag fallback
Centered device detail panel with school, holder, status, and condition
Recent activity feed for the latest scans and actions
Bulk issue mode with class selection, running count, and undo
Damage found on return becomes a finance review queue, not an automatic charge

Build a Device Register with ToolJet MCP for Trust Teams

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements now live in one prompt you could have used from the start. Read it as a single-shot specification, then use it to recreate the same app without reconstructing the earlier iterations.

Build a 3-page device register app in ToolJet for Northline Learning Trust, a multi-academy trust with 11 schools, to replace per-school spreadsheets for laptops and tablets. No permissions system for now, every signed-in user can act as any staff member.

Page 1, Scan & Record, is the home page. Staff scan a device's asset tag with the camera or type it manually, then see the device's school, current holder, status, and condition in a centered panel that starts greyed out before a scan. From there they can issue to a pupil or staff member, return, move, or write off a device, with a recent-activity feed and a bulk issue mode for the September rollout, including class selection, repeated scanning, and undo. Issuing to a pupil captures the accepted-by name. Returning a device can record damage from a fixed damage-type list with an optional photo, and any damage creates a proposed charge for later finance approval.

Page 2, Register, is a searchable table of every device with school and status filters, plus a modal that shows current details and the full movement history. Page 3, Summary, shows owned, on loan, overdue, and written off this year as a KPI strip, a grouped chart across all 11 schools, and a queue of proposed damage charges with Approve and Reject actions.

Use schools, staff, classes, pupils, a fixed damage-type list, devices, device movements, loan agreements, and damage charges. Device movements are the audit trail, loan agreements capture the accepted-by record, and damage charges stay proposed until finance acts. Design it as enterprise-grade but warm and approachable, with warm oranges, soft shadows, rounded corners, muted colours, a trust-naming header band, the signed-in-as identity and logout control inside it, and one consistent panel type size.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, not just the screen, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. Enterprise app building does not end at the interface, because data connectivity, workflows, permissions, deployment, and ongoing change still sit behind the register, and the generated app lives on a runtime that carries those where supported instead of handing you a codebase to operate alone. The path stays open after generation, with visual editing for normal changes and code where a device rule or data transform needs it.

Data Created

The app ended up with 9 tables, split across the trust roster, the device ledger, and the finance trail. schools, staff, classes, and pupils anchor who can hold a device, damage_types and devices define what the register knows, and device_movements, loan_agreements, and damage_charges keep the history and review queue tied to each asset.

Page	Components	What they cover
Scan & Record	57	Scan or type an asset tag, see the device panel, and issue, return, move or write off a device, plus bulk issue mode
Register	13	Searchable register of every device with school/status filters and a full history modal
Summary	10	Per-school breakdown chart, KPI strip, and the damage-charge approval queue

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	9
Queries	32
Components	80
Code files to maintain	0
Repair cycles	1
Final validation	0 error

Industries That Run This

Multi-academy trusts and school IT teams are the direct fit here. The same pattern, a scannable asset register with an issue, return, move or write-off lifecycle, loan agreements, and damage charges routed for approval rather than auto-applied, suits any organisation that hands out shared hardware to people it doesn't directly employ or fully control: universities issuing laptops to students, healthcare trusts tracking mobile devices and equipment across wards, and corporate IT teams managing a loaned-device fleet across offices.

Who Gets Access To The Built App

Permissions were explicitly left out of this build. Anyone signed in can pick any staff identity from the header and act as them: issue, return, move or write off any device at any school, and approve or reject any damage charge. It's built as a shared operational tool for school IT staff, not a role-restricted system; adding real per-school or per-role access control would be a natural next phase.

Enterprise Features for Your Device Register App

A device register holds asset tags, pupil names, and loan agreements. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

ToolJet Workflows adds the notification layer. One workflow fires when a damage charge is approved, posts the finance decision in Slack, emails the school through Gmail, and writes the result back to damage_charges.

Final Takeaways

This build shows a trust-wide device register can move from one prompt to a working app that handles scan, register, summary, and finance review flows around the same shared data. The result matters because the agent produces a structured application on ToolJet's runtime, so the team keeps editing the app instead of inheriting a code export and its upkeep. That model leaves room for visual changes, targeted code when a rule is special, and the data, workflow, and governance layer that keeps device history, damage review, and future changes in one place.

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own device register for a multi-academy trust, then request a ToolJet demo.

FAQs

What does ToolJet MCP do for a device register?

ToolJet MCP turns a written brief into a working ToolJet app by shaping the register's pages, data, and interactions together. For this build, that means a scanner-led device register rather than a static mockup or a pile of scripts.

What does the Device Register app actually do?

The app tracks laptops and tablets across 11 schools, then lets staff issue, return, move, and write off each device. It also keeps movement history, loan agreements, and damage charges attached to the same record.

How do you reproduce the build from the prompt in this article?

Use the prompt in this article as the full specification and run it as one build request. The same pages, tables, and rules can be recreated without turning the brief back into a manual checklist.

Do you need to write code for the scanner and history views?

Not for the core flow. The app shows the scan panel, device details, recent activity, register filters, and history modal as part of the generated application, and you only drop into code when a special rule needs it.

What happens after the agent finishes, is this just a UI generator?

No, the output is a structured ToolJet application that keeps the data, queries, and interface together on the runtime. You keep editing the app visually, add code where needed, and let the same project carry the device rules forward.

Can the app use your own device data?

Yes, the same register shape can point at your own trust data instead of the seeded demo content. The device list, movement log, loan records, and damage queue are all built around that shared model.

Can several people keep building on the same Device Register app?

Yes, the same ToolJet app stays as one shared project, so different builders can keep extending the register without splitting the logic across separate copies. That helps when the trust updates device rules or adds a new school process.

Build an Asset Handover App with ToolJet MCP

Athulya R — Wed, 16 Sep 2026 16:15:05 +0000

Introduction

Build an asset handover app with ToolJet MCP for the counter team that checks out power tools, survey gear, and site laptops from a tablet. The app shows who has each asset, what condition it was last recorded in, and what needs to happen next at handover. You get the screen flow, the data model, and the prompt in this article, and an agent generated the result as a structured ToolJet application with data, queries, and interface together, not a screen or a code drop.

Equipment List — KPI tiles, category breakdown, recent activity, and a searchable, filterable table with an overdue view

Item Detail — full movement history with condition photos, and an Asset-Manager-only correction flow

Scan & Record — QR scan with a manual-code fallback, big Issue/Return/Transfer buttons

What We're Building

This app uses a wide scan-and-record page and a separate equipment list page, both tuned for tablet use. On the scan page, a big QR scanner sits with manual code entry, a match reveals the asset's name, category, holder, and condition, and a miss opens a centered register form for a new item. The same screen then drives the handover action with Issue, Return, and Transfer controls, recipient and condition fields, an issue date picker, photo capture for returns, and a single confirm step, while the layout keeps the manual code entry and camera view from overlapping. The confirm step returns the tablet to scan-ready state, and the equipment list shows summary tiles, a category chart, recent activity, search, filters, and an overdue view that sorts from most overdue first, while row clicks open the hidden item detail history with notes beside each photo.

Scan a QR code or type a manual code to land on the right asset record
Register a new asset inline when the code does not match an existing item
Record issue, return, and transfer movements from one compact screen
Attach return photos to the movement record and keep the history append-only
Review equipment with summary tiles, a category chart, recent activity, and an overdue list

Build an Asset Handover App with ToolJet MCP for Scan, Record, and Review

Want to build it yourself? Start with the ToolJet MCP repository for setup instructions, supported agents, and everything you need to follow along.

The Consolidated Build Prompt

The build took several passes, and the requirements are consolidated here into one prompt that could have driven the app from the start. You can use the prompt in this article to reproduce the same structure in a single run.

Build a 2-page tablet app for a commercial construction equipment store to replace a paper asset-handover ledger. Use ToolJetDB for two tables: items (code, barcode_value, name, category, status, current_holder, current_condition, expected_return_at) and movements (an append-only log of every issue/return/transfer, with from/to holder, condition before/after, notes, photo_urls, and a corrected/corrected_by/corrected_at trail) — an item's current state is always derived from its latest movement, never overwritten in place.

Page 1, Scan & Record: a big QR scanner with a manual-code fallback above it. On a match, show the item's name, category, current holder, and condition immediately. On no match, show an inline register-item form (name, category, condition) that generates a new code and continues straight into the movement step. One screen with three big Issue/Return/Transfer buttons, a recipient field, a condition-now field, an expected-return date picker for Issue, and a 1-2 photo capture step for Return that uploads to S3 and attaches the URLs to the movement record. A single Confirm button submits the movement and returns to scan-ready. Center the register-item form; keep the manual code entry and camera view from overlapping.

Page 2, Equipment List: KPI tiles for total/available/issued-or-transferred/overdue counts, a category breakdown chart, a recent-activity feed, and a searchable/filterable table of all equipment showing current holder and last-moved time, with an Overdue tab sorted most-overdue-first. Row click opens a hidden Item Detail page with the item's current state and full movement history, each entry showing its condition note next to its photos.

Two ToolJet groups, Operators and Asset Managers. Both can scan/record movements and view full history read-only. Only Asset Managers can correct a mistaken movement record (enforced on the correction query itself, not just hidden in the UI) — correcting the latest movement recomputes the item's current state. Apply a custom muted theme and seed realistic sample data across all equipment categories and statuses so the app doesn't demo empty. Keep the app to exactly 2 top-level pages.

How ToolJet MCP Builds the App

ToolJet MCP works through the whole application, so the data model, pages, components, queries, and the wiring between them land as one structured ToolJet application. That matters here because the handover flow depends on current state, movement history, photo storage, and role-gated correction, and the generated app sits on a runtime that carries data connections, workflows, and permissions where supported instead of handing you a codebase to operate yourself. The same structure lets the scan page, the equipment list, and the hidden item detail view stay in sync, and you can keep editing visually and drop into code where the case calls for it.

The One Thing That Broke

A printed QR scan sometimes opened the wrong item because the decoded value carried trailing whitespace, so exact matching failed. Trimming the scanned code fixed the lookup and the handover flow picked up the correct asset again on every scan.

Data Created

The app ended up with two tables. items stores every tracked asset, including its code, category, current holder, current condition, and expected return date, while movements keeps the append-only log of issue, return, transfer, correction, notes, and photo URLs that drives the current state. The current holder and condition come from the latest movement instead of being overwritten in place, so the log stays authoritative.

Page	Components	What they cover
Scan & Record	26	Scan/lookup, register-unmatched-item, and the issue/return/transfer flow with photo capture
Equipment List	15	KPI dashboard, category chart, recent activity feed, searchable table, and overdue view
Item Detail (hidden)	22	Full movement history with condition photos and an Asset-Manager-only correction flow

What Got Generated

Metric	Result
Pages	3
ToolJet DB tables	2
Queries	16
Components	63
Code files to maintain	0
Repair cycles	1
Final validation	0 errors

Industries That Run This

Commercial construction and equipment rental — any company that hands physical power tools, survey equipment, or site laptops between crews and needs an auditable record of who has what and in what condition, without relying on a paper sign-out sheet.

Who Gets Access To The Built App

Operators can scan items, record issues/returns/transfers, and view full item history read-only. Asset Managers get everything Operators have, plus the ability to correct a mistaken movement record after the fact — enforced server-side on the correction query itself, not just hidden in the UI.

Enterprise Features for Your Asset Handover App

An asset handover app holds asset codes, holder names, and photo evidence. ToolJet covers that governance at the platform layer, so you configure it once instead of rebuilding it in every app.

SSO and SCIM: sign in with SAML, OIDC or LDAP, and provision users automatically
Role-based access control: scope permissions to the app, the data source, and each query
Audit logs: track every login, edit, and approval decision for compliance review
Air-gapped deployment: self-host on Docker or Kubernetes so your data stays in your network
Multiplayer editing: several builders work on the same app, with versioning and Git sync
ToolJet AI inside your own deployment: run the AI features in your tenancy rather than a shared service

Final Takeaways

This build shows a tablet handover app that scans a code, exposes the current holder and condition, and records issue, return, transfer, and correction events against a log that stays authoritative. The point of the structured application model is that the agent hands back a real ToolJet app on a mature runtime, so you keep editing the same project instead of inheriting loose generated code. Visual editing, selective code, data connections, and permission rules stay in one place as requirements change, which is the part that matters after the first version ships.

Cost and Speed by Model

Model	Credits	Minutes	Notes
Astra	290 to 550	13 to 16	The most polished pages, when cost matters less
Sol (Recommended)	300 to 650	14 to 22	The best balance of quality and cost for most apps
Terra	85 to 210	5 to 12	The fastest, and best kept to smaller apps
Luna max	35 to 55	33 to 62	The most complete Luna, and by far the slowest
Luna high	25 to 50	22 to 41	Mid-effort Luna, between medium and max
Luna medium	10 to 30	14 to 20	A quick first draft or a small tool

Even averaging across model tiers, ToolJet MCP can turn $10 into a dozen or more working 4-page apps.

Try ToolJet MCP

Build your own asset handover app, then request a ToolJet demo for your equipment data.

FAQs

What does build an asset handover app with ToolJet MCP create?

It creates a structured ToolJet application for asset handovers, not a loose export. In this build, the scan flow, equipment list, and hidden item history page land with their data and query wiring intact so the app keeps working as one unit across review and correction.

How does the app handle an unknown QR code?

A miss opens the register-item form on the same screen. You enter the asset name, category, and first condition, then continue straight into the handover step with a new code, without leaving the scan flow or losing the context of the match.

Do you need to write code to reproduce the flow?

No code is needed for the base flow. The prompt sets up the pages, tables, and actions, and the generated app still leaves room for code when a specific case needs it, such as a custom check or a specialized lookup rule.

How does this app use ToolJetDB and S3?

ToolJetDB stores the tracked assets and the append-only movement log. S3 holds the return photos, and those URLs stay attached to the movement record so the history keeps the evidence with it while the scan flow reads the current state from the latest movement.

What happens to the app after the agent finishes?

The finished app stays as a ToolJet project on the runtime, so you keep editing the same data model, pages, and permission rules instead of taking over a one-off generated artifact. That keeps the asset process in one place as the process changes.

How do Operator and Asset Manager roles differ?

Both groups can scan, record, and read history. Only Asset Managers can correct a mistaken movement record, and that restriction is enforced on the correction path itself, not just hidden in the interface, so the server-side rule matches the visible control.

Can several teammates keep working on the same app?

Yes. Different people can keep iterating on the same project, and the shared tables and screens keep the asset catalog, scan screen, and permission logic aligned as requirements change without splitting the handover process across separate copies.

Building a Recall Response Console With ToolJet MCP (and Examining ToolJet’s Approach to AI App Building)

Karan Rathod — Mon, 14 Sep 2026 20:14:59 +0000

Building the first version of an internal application is only one part of the job. The more difficult challenge is keeping it useful as the process, data, and people around it continue to change.

Internal tools are constantly evolving. Operations asks for another filter. Finance adds an approval step. Compliance updates a process. A team needs a new field, a different table layout, or another way to query the same data. Individually, these are small requests. Across dozens or hundreds of internal applications, they become a much larger maintenance problem than the initial build.

For this tutorial, we wanted to show what that approach looks like in practice. We gave Codex a detailed brief for a manufacturing recall system and used ToolJet MCP to build it. The resulting application is large enough to take us through the structure of a ToolJet MCP build—from planning and validation to queries, components, and later iterations—and to show how the finished app remains editable inside ToolJet.

The final application had 10 tables, 109 seeded rows, 28 queries, and 109 components across three pages.

ToolJet MCP Repo: https://github.com/ToolJet/tooljet-mcp

ToolJet MCP did not generate a complicated React codebase and hand it over. It used ToolJet’s own APIs to create pages, components, queries, events, layouts, and data inside the platform. Once Codex finished, the result was still a normal ToolJet application. That is a fairly important difference when the person maintaining the app later may not be the person who prompted it into existence.

The App We Asked Codex to Build

The original brief was around 1,400 words. It described a Recall Response Console for a manufacturing company in South Australia, used by quality, operations, compliance, supply-chain, and customer-response teams.

The main instruction was simply:

Build this application in ToolJet. Follow the attached brief, keep the data consistent across every page, and verify each phase before moving on.

The first page was a Recall Command Centre. It needed portfolio-level KPIs for active recalls, units at risk, recovered units, financial exposure, and completion rate. Below that, the highest-priority recall had its own spotlight with severity, recall reason, affected batches, unit counts, and regulatory status. We also wanted the progress of affected inventory to be visible from production all the way through recovery.

The page included a portfolio table covering every recall. Users could filter by status, severity, category, owner, date, and region, and search across products, SKUs, lots, and recall IDs. The lower half added views for recovery, exposure, geographic distribution, and recall activity.

Clicking a recall opened the second page, the Recall Case & Response Workspace. This was designed for the team handling an individual recall rather than monitoring the whole portfolio.

The selected case shows 18,420 affected units, 16,210 located, 13,840 quarantined, and 11,920 recovered. The page follows the response from Issue Detected through Investigation, Recall Initiated, Containment, Recovery, Verification, and Closed. It also includes affected production lots, a distribution trace, stakeholder communication, response actions, root-cause investigation, and an audit trail.

We later gave Codex one much shorter follow-up instruction:

Add another relevant page with urgent actions.

Because the data model and application structure already existed, this did not need another large specification. Codex reused recall_actions and turned the request into a cross-recall Response Desk. For the iteration review, it produced one focused HTML artifact rather than another bundle of disconnected files.

The Response Desk pulls urgent work across recalls into one queue and groups it around overdue, due today, blocked, and critical actions. A user can complete an action from the queue or open the related recall for more context.

The app itself is useful, but it also gives us enough surface area to look at how ToolJet MCP approaches generation.

ToolJet MCP Is Not Just Generating More Frontend Code

A common direction in AI app building is to make the coding agent better at producing larger amounts of application code. In many cases, that means generating React components, data-fetching logic, state management, and the glue needed to connect everything together.

That approach can work very well when the output is supposed to be a codebase. The trade-off is that every generated app also becomes another codebase that somebody has to understand and maintain.

Internal apps tend to make that trade-off more visible. One company may have a large number of small operational tools, each with a different owner and a different lifespan. Many of the people maintaining them will understand the business process far better than they understand React.

ToolJet MCP takes a different route. Instead of asking the model to generate the application framework every time, it exposes smaller APIs for working with the framework that already exists.

Codex(or any other coding agent) can create a page, add components, configure queries, work with the ToolJet Database, connect events, change layouts, and update existing objects. The model still decides what needs to be built, but it does not have to express every part of that decision as frontend code.

That keeps the output inside ToolJet’s application model. A table created through MCP is still a ToolJet table component. A database operation remains a ToolJet query. A page created by the agent still appears in the normal page structure.

This also gives the agent a much narrower surface to work with. It can ask the platform to perform a specific operation rather than repeatedly producing large blocks of code and then reasoning about the result.

The Build Happened in Validated Phases

The MCP did not try to write the entire application in one enormous operation.

Plan the next phase
        ↓
Validate it
        ↓
Fix validation errors
        ↓
Apply the phase
        ↓
Verify the result

Before a phase could be applied, the proposed application specification was linted. A successful lint produced a temporary token that was then consumed by the write operation. If linting failed, that phase did not get written.

That validation caught several real problems during the build. One database column was using a reserved SQL keyword. Another binding could reference a component before it had mounted. One action was targeting a component with the wrong property. Those issues were rejected before the corresponding phase was applied.

This does not make AI-generated apps magically error-free. It does give the agent a more structured way to fail. A bad change can be rejected as an invalid application operation rather than first becoming a large piece of broken code that has to be debugged afterwards.

The same idea applies to components. The platform already knows what a table, container, input, or query is. The agent can work with those contracts rather than inventing its own version each time. That is a more useful abstraction when trying to keep token usage under control as apps become larger.

Why Token Usage Fell Across the Build

The runtime exposed an approximate budget counter during this build. It is not a precise usage meter and should not be treated as an API bill, but the pattern was useful.

The first major turn, covering planning, the data model, and Page 1, used roughly 190k tokens. Page 2 and its mutations used around 84k. The later Response Desk iteration used about 51k.

The first pass had much more work to do. Codex had to read platform references, understand component contracts, establish the data model, and create the initial application structure.

Later work could reuse those decisions. When we added the Response Desk, ToolJet MCP did not need to create another data model. It reused recall_actions, added the required rows, and built the page on top of the existing application. The component types were already known and the broader application structure was already in context.

The practical benefit is not only lower token usage. It also means later changes fit into the same application model rather than slowly turning the project into a collection of generated code paths.

You Are Not Forced to Keep Using AI Afterwards

Once your app is ready, the next change does not have to go through Codex.

For a larger feature, it probably makes sense to continue using ToolJet MCP. The agent already understands the structure and can make coordinated changes across the application. For a small UI change, someone can simply open ToolJet.

The generated table remains a normal ToolJet component, editable through the visual builder.

The visual builder still sees the components normally. A user can resize a table, move it, change its styling, modify properties, or add another component without touching the process that generated the original page.

We did not spend a lot of time manually editing this app after the MCP build. That is not the point of showing the visual builder. The value is that the generated app has not lost the normal editing model of the platform.

The same applies to the data layer.

The query created during the build is still understandable in GUI mode: update recall_actions where the row ID matches the selected action.

A query created during the MCP build can still be opened in ToolJet’s query editor. In GUI mode, a user can see the data source, table, operation, and filters without tracing generated code. Someone comfortable with SQL can work in SQL mode. Someone who is not can use the GUI.

That is crucial for internal software because maintenance often ends up with the person who understands the workflow rather than the person who originally built the app.

This Is a Different Bet on AI App Building

There are two ways to look at an AI agent building software.

One is to keep making the agent better at producing code. Better models produce cleaner components, larger applications, and fewer mistakes. For some types of software, that is exactly what you want.

The other option is to give the agent better abstractions to work with.

ToolJet MCP follows the second approach. The model still does a lot of the difficult work. It reads the brief, plans the application, decides how to structure the pages, creates the data model, and connects the interactions. The platform handles the parts that already have a well-defined representation.

A table does not need a new React implementation. A database update does not need another custom data-access layer. A page does not need to become another routing problem.

That is also why this model makes sense for internal applications. The first build can be fast without turning every app into a new engineering project.

If a company eventually has hundreds of internal tools, the ability to generate them is only one part of the equation. They also need to be understandable and changeable after the person who created them has moved on.

What This Build Left Behind

By the end, we had a three-page Recall Response Console with a real data model, working queries, cross-page navigation, response actions, and enough operational detail to make the app useful beyond a demo.

More importantly, the result still behaved like a ToolJet application.

Codex, Claude Code or any other agent could continue making changes through MCP. A developer could work directly with SQL where needed. A business user could work with a query through GUI mode. Someone could open the visual builder and adjust a component without first learning how an AI agent generated it.

That is a different outcome from generating another React codebase, even if both approaches can produce a very similar screenshot.

For enterprise internal tools, that distinction becomes more important as the number of applications grows. Generating software is getting cheaper very quickly. Keeping all of that software maintainable is going to be the harder problem.

ToolJet MCP is built around that assumption.