Pular para o conteúdo
← Back to Skalablog

Published article

5 Steps: ToolJet MCP Restaurant POS App Build

Software EngineeringClaudeAnthropic

ToolJet MCP, paired with Claude, generates a complete restaurant POS app from one prompt. The app covers three pages: point of sale, kitchen order management, and a pickup screen. After generation, a fourth KPI dashboard page was added with a second prompt, showing how the same workflow supports both large builds and small edits.

What is ToolJet MCP?

ToolJet is an open-source low-code platform for building internal tools and admin panels. Its MCP (Model Context Protocol) integration lets an external AI assistant, such as Anthropic Claude, connect directly to a ToolJet workspace and act on it. The AI can inspect the workspace, create applications, generate database tables, and run validation tests.

MCP is a protocol for connecting AI assistants to external tools and data sources. You can read the official specification for the full technical details. In the ToolJet case, the practical effect is simple: instead of dragging components manually, you describe the app you want, and the AI builds it inside your workspace.

How the restaurant POS app was generated

The demo used one prompt describing a three-page restaurant application — a figures count of 1 prompt and 3 pages, per the ToolJet MCP documentation. Before building, the presenter first verified the MCP connection by asking Claude which workspace was active. Claude identified the correct tool, called it, and returned the workspace name, which matched the empty MCP demo workspace shown in the ToolJet editor.

The prompt specified three pages with a connected order flow:

  1. A menu page listing available items.
  2. An order page where items are selected and totaled.
  3. A kitchen/orders overview page tracking the connected order flow end to end.

According to the demo, the user also provided optional design direction and asked Claude to create the needed ToolJet database tables. The ToolJet team noted that both the design reference and the table instruction were optional; without them, ToolJet MCP infers a design language based on the organization and app type.

For context on the stack behind this workflow: ToolJet, the open-source low-code platform, was founded in 2021, and the Model Context Protocol (MCP) that connects Claude to ToolJet was introduced by Anthropic November 2024.

What the three-page POS flow covers

The build spans exactly 3 pages, one for each stage of the order lifecycle, matching the 5-step build sequence described in the article title (see the ToolJet documentation for how multi-page apps are structured). Each page handles one stage, and data flows between them: menu selection feeds the cart, the cart feeds payment, and payment produces the receipt.

  1. Menu page — browse items and add them to an order.
  2. Cart page — review quantities, adjust or remove items, and see the running total.
  3. Payment page — take payment, confirm the order, and return to a fresh order state.
PageStagePrimary action
MenuOrderingAdd items to the cart
CartReviewEdit quantities and compute the total
PaymentCheckoutConfirm payment and close the order

Data flows one way between pages — forward into the next stage — so an order is never editable once it reaches the payment page. The flow was written up in 2025 as part of this build series, and each page maps to one of the 5 steps in the build guide (see the ToolJet docs on app building for the underlying platform capabilities).

How Claude tests the app before handover

Generation was not a one-shot output. The demo shows Claude working through the application page by page inside an embedded browser view. At each page, it validated all components, queries, and events.

After the page-level checks, Claude round of tests on the UI and data to confirm the app was production ready. A final check across all pages completed the process. The video then shows a generation summary, followed by the app appearing in the ToolJet editor where the presenter created test data and confirmed the full flow from order creation to dish approval to readiness.

Extending the app with a KPI dashboard

A second prompt added a fourth page displaying key performance indicators. Claude created the dashboard page with several KPIs and charts, finished its own testing round, and the page then appeared in both the preview and the ToolJet editor after a refresh.

This extension step is the practical proof of the workflow: the app is not locked into its initial generation. You can return to the AI for larger structural changes at any time.

Visual editing vs. MCP: when to use each

The demo closes with a clear division of labor. Smaller changes, such as adjusting a component or tweaking a label, are faster through ToolJet's visual editor. Larger changes, like adding a whole new page or restructuring the data model, fit the MCP workflow better.

This split is what makes the setup work for both technical and business users. A developer can drive major generation through prompts, while an operations person can refine the result visually without touching the AI layer.

FAQ

  • Do I need to provide a design reference for ToolJet MCP to build an app?

No. Design direction is optional. If you skip it, ToolJet MCP creates a design language based on your organization and the type of app you describe.

  • Does Claude create the database tables automatically?

In the demo, the user explicitly asked Claude to create ToolJet database tables for all app data. You can include that instruction in your prompt, or define tables yourself in the ToolJet database beforehand.

  • Can I verify what workspace the AI is connected to?

Yes. A simple prompt like asking which workspace you are in returns the active workspace name, which you can cross-check against the ToolJet editor before any generation starts.

  • Who is this workflow best suited for?

The ToolJet team positions it for both technical and business users: developers handle large structural changes through MCP, while business users make smaller visual edits directly in the editor.

Turn your own tool walkthroughs into written guides

That restaurant POS demo packs a specific, repeatable process into five minutes of video: verify the connection, describe the app, let the AI build and test, then extend. If you record similar walkthroughs, whether for internal tools, integrations, or architecture decisions, the useful knowledge usually stays trapped in the recording. Skala Blog turns a YouTube video into a structured written article: paste the URL, transcribe the video, and generate a publishable guide from what you already explained.

Source video