Build a Fleet Operations Dashboard with ToolJet MCP

Introduction

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 1 home

fleet metrics 2 vehicle detail

What We're Building

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

Build a Fleet Operations Dashboard with ToolJet MCP for Telemetry 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 use the prompt in this article to reproduce the same app in one shot.

Build a two-page self-serve ToolJet app called Fleet Operations Dashboard for a fleet operations team running electric delivery vans across multiple depots.

Page 1, Fleet metrics, lets supervisors explore telemetry by metric, depot, model, driver or week, compare against fleet and depot averages, save shared views, and review charts, KPI tiles and a breakdown table. Page 2, Vehicle detail, lets a user pick one van, read a plain-English summary, inspect its identity card, trend chart, peer comparison gauge, maintenance context, exception flags and daily readings table.

Use a clean, light, spreadsheet-adjacent visual style, with white surfaces, a light page background, one accent blue, hairline borders and compact hierarchy.

Use InfluxDB for telemetry and Supabase Postgres for vehicle, depot, model and driver data. Do not use ToolJet DB. Derive fleet size, depot count and date range from live data so the app keeps working as the fleet changes.

Model the app with fleet_saved_view, vehicle, depot, model and driver. Keep saved views visible to the team, but gate the save control so only the fleet director can create them in the UI.

Aggregate everything in InfluxDB with parameterized Flux. Distance and hours sum, energy per km is a mileage-weighted mean, battery health uses the latest reading per vehicle before averaging, and utilisation is a simple mean.

Bind every Plotly chart to a query that returns an already-stringified JSON figure, and export every chart and table to CSV.

How ToolJet MCP Builds the App

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.

The One Thing That Broke

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.

Data Created

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.

Enterprise Features for Your Fleet Operations Dashboard

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

Final Takeaways

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.

Try ToolJet MCP

Build your own fleet operations dashboard with ToolJet MCP, then request a ToolJet demo to map it onto live telemetry.

FAQs

Is this just a UI generator?

No, the result is a structured ToolJet application, so the data model, queries, pages and component wiring stay together after generation. You keep editing the same app in the runtime instead of taking over a separate codebase when the agent finishes.

What does ToolJet MCP do for this fleet dashboard?

It turns the prompt in this article into a two-page ToolJet build with live telemetry queries and the page structure already connected. The same prompt also covers the saved-view flow, the single-vehicle drilldown and the comparison logic.

What does the Fleet Operations Dashboard show?

The first page compares depot, model, driver and week views across distance, energy efficiency, battery health, hours in service and utilisation, with fleet averages folded into the same view. The second page drills into one van with recent readings, maintenance status and rule-derived exceptions.

Can I reproduce it from the prompt in this article?

Yes, the condensed prompt is written so you can start from one specification and rebuild the same app in a single shot. It already includes the pages, the visual direction, the data sources, the metric rules and the shared-view behaviour.

Do I need to write code for the charts and metrics?

No, the metric work belongs in Flux, not in JavaScript. The chart components bind to the query output, and code only comes in when a particular interaction or visual shape needs an exception.

Can I connect existing telemetry and master data?

Yes, the dashboard is built around existing InfluxDB telemetry and Supabase Postgres master records. The app derives comparisons from live data, so the vehicle count and depot structure come from the sources instead of hardcoded values or fixed assumptions.

Can several people work on the same dashboard?

Yes, the app lives as one shared project, so teammates review and refine the same structure rather than cloning separate copies. The saved-view list gives the team a common set of named configurations to work from.