You build a fleet operations dashboard with ToolJet MCP for depot supervisors and fleet managers who need live answers on electric van performance without waiting for an analyst. An agent generated the app, and the result is a structured ToolJet application, with data, queries and interface working together, not a screen or a code drop. The app gives the team one place to answer operational questions that would otherwise need manual slicing of telemetry and master data. The rest of this tutorial shows the finished dashboard and the prompt in this article so you can reproduce the same internal app on your own fleet data.

Fleet Metrics Home Page

Fleet Metrics Page 2: Vehicle Details

The first page is an exploration surface, with metric, breakdown, depot and period controls driving KPI tiles, charts and a sortable table. A saved-view panel sits underneath, so the fleet director can store one combination for the rest of the team. The second page narrows to one van, with a search picker, a plain-English summary, an identity card, a trend chart, a peer comparison gauge, maintenance context and a table of daily readings. Each block answers a different operational question, and the layout keeps the comparison view and the vehicle view close enough to move between them without leaving the app.

• Two pages, fleet comparison and single-vehicle detail
• Metric, breakdown, depot and period controls
• Shared saved views for the fleet director and team
• Comparison against fleet and depot averages
• Derived exceptions, maintenance context and CSV exports

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

The real build took several passes, and the requirements are consolidated into one prompt that could have been used from the start. You can use the prompt in this article to reproduce the same app in one shot.

ToolJet MCP works through the whole application, not just the screen, because the data model, queries, component tree 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 are the rest 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, so you can use AI generation, then visual editing, then code where a case needs it.

A read-only saved views panel went blank even though the row still existed in Postgres. The cause was a shared label-shaping query, where an edit for a new heading had been made against an older cached version and silently dropped the HTML that rendered the panel. Fixed.

The app ended up with five tables. fleet_saved_view was created by the build to store the shared view name, metric, breakdown, depot and saver details, while vehicle, depot, model and driver provide the master records that fill the selectors, labels and comparisons.

A fleet dashboard handles driver names, depot assignments, and vehicle maintenance status. 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

This build shows that a fleet supervisor can start from live telemetry and master data, then land on a dashboard that compares depots, explains one vehicle and keeps a shared saved-view list for the team. The important part is that the output is a structured ToolJet application, so the pages, queries and bindings stay in the same place after generation. You can keep refining the interface visually, drop into code when a metric rule or interaction needs it, and rely on the runtime for the data and workflow pieces where supported instead of scattering the app across separate files. That keeps later change inside the app model, not in a rewrite.