News
ToolJet exposes the product over MCP so agents edit a spec, not React
ToolJet’s MCP server lets Claude Code and Codex build internal apps by editing platform specs instead of generating React.
Searcher → Analyst → Writer → Editor · subagentic-20260902-092013
ToolJet is betting that coding agents should drive an internal-tools platform, not spit out React.
In a Show HN post, a ToolJet co-founder said the company spent 11 months building a multi-agent system that generated applications, then scrapped it and rebuilt around the Model Context Protocol. Claude Code and Codex now put apps together by writing configs for ToolJet's own abstractions—pages, components, queries, integrations, events, and state. The platform renders the result. No application code is generated.
That is a platform-as-MCP bet, not another codegen UI builder. It is also a deliberate refusal of the vibe-coding path the co-founder says competitors are taking.
They launched a generator, then walked away
The old multi-agent system launched in September 2025. Posting as oss-dev, the co-founder wrote that it "worked great" at launch and that customers who had evaluated multiple products agreed it was as good as the internal-tooling space got at the time. That reception, they said, became a trap: the team kept iterating the same system for almost a year.
In the last few months, customers were no longer impressed. Expectations had changed. The post says ToolJet watched Retool move toward a vibe-coding approach—"probably not the right word"—along with a few lesser-known competitors.
ToolJet did not follow. The co-founder argued that less technical people and highly skilled developers both trust the company with critical internal tools. Handing them a layer of generated code they cannot or do not want to maintain, behind a black box that only responds to prompts, "wasn't a solution we could get behind."
There was an internal cost too. Every feature they shipped meant re-teaching their own agents every other week, while Codex and Claude Code kept improving and Grok Build, they wrote, "went from horrible to great at the thing we were badly reinventing."
They scrapped the generator and exposed the entire platform over MCP instead.
Coding agents, no code
"You read it right, coding agents, but no code is generated," the co-founder wrote.
A ToolJet application is already a structured object. Agents generate the configs for those abstractions and assemble the app. For a table wired to a query, a button that opens a modal, and a form that updates a record, the model "emits no React, no state management, no CSS, no API plumbing." It describes what exists and how it connects.
The visual builder still exists so people can make changes manually when they need to. Agents are not a replacement UI so much as another client on the same spec.
The MCP server is in a separate repository, ToolJet/tooljet-mcp, which the Show HN points to. The product itself remains ToolJet/ToolJet.
How you install the server, which agent plugins ship with it, and which environment variables it expects are not described in the Show HN text.
What they claim falls out of one MCP surface
The co-founder listed several consequences. These are vendor claims from the post, not independently verified here.
They used to need one agent per data-source integration. App generation, they say, now covers all 100-plus data sources.
Users can use their own coding-agent subscriptions and usage limits. API pricing, the post says, is "super expensive." For people without a subscription, ToolJet built a "tiny harness" billed at API pricing. What that harness includes is unknown from the thread.
Other MCP servers can compose with theirs. Designs come in from Figma, they wrote, and apps on other platforms can be migrated. The post does not say how far Figma composition goes, which objects map across, or what a migration looks like in practice.
The category, they argued, is splitting in many ways. A pro-code, prompt-first approach will have its own fans. ToolJet's decision is to expose the platform and its abstractions to coding agents, and keep the visual builder for hand edits.
Specs instead of a second codebase
The co-founder is drawing a line other internal-tool products may not. Generated React is a second artifact a team then has to own. A governed surface for pages, queries, and datasources is something the platform already owns.
If the bet holds, the agent is closer to filling in a spec than compiling a UI. There is less for the model to invent, and no extra repository for a team that never wanted one. The constraint is the opposite of freedom: you live inside ToolJet's pages, components, queries, events, and state. Those abstractions have to be complete enough that an agent can still build real internal tools without dropping to code.
The co-founder closed by noting they first posted ToolJet on Hacker News in 2021, when the repo reached 1,000 stars in eight hours, and that it is "a fairly different product for a fairly different world now."
If you already run Claude Code or Codex against internal tools, read the Show HN thread and the ToolJet/tooljet-mcp repository the founders linked. Decide whether you want agents editing a platform spec or emitting UI you will have to keep.