I've spent enough time in production environments to know that most 'AI integrations' are actually just glorified copy-paste loops. You see a great piece of data in your dashboard, you manually export it as JSON, and then you paste it into Claude asking for a summary. It works for a demo, but it's fundamentally broken for real engineering work.
The real shift—the one that actually changes how we run systems—isn't about better LLMs. It's about the Model Context Protocol (MCP). When an agent can actually reach into your stack, query your databases, and trigger a workflow without me acting as the human middleware, that's when things get interesting.
I was recently looking at how we could bridge the gap between low-code environments like ToolJet and these emerging MCP-compatible clients (Cursor, Claude Desktop, etc.). If you use ToolJet, you already have your business logic in one place. The problem is that traditionally, that logic is trapped behind a UI designed for humans.
The Problem with 'Read-Only' Agents
You see this everywhere: an MCP server that only lets you read data. Sure, it's great if I want to ask, "How many pending orders do we have?" But as an engineer, my job isn't just monitoring; it's responding. If the agent finds a critical error in a ToolJet entry, and the only way to fix it is for me to manually navigate through three layers of ToolJet menus to click 'Retry,' then I haven't actually automated anything. I've just moved the bottleneck.
When we built the ToolJet MCP server for Vinkius, we focused on the transition from discovery to execution. It isn't enough to list_tables. You need the ability to act.
Breaking Down the Toolset
If you look at what this specific implementation provides, there are four primitives that define the agent's capability.
1. The Discovery Phase: list_tables and query_table
An LLM is useless if it doesn't know the schema. The list_tables tool is the first thing an agent calls. It inspects your ToolJet Database workspace to build a mental map of what data actually exists.
Once the structure is known, we move to query_table. This isn't just a simple key-value lookup. Because it supports SQL SELECT statements, you can perform joins and complex filtering via natural language. If I tell Cursor, "Find all customers from Brazil who haven't placed an order in 30 days," the agent constructs the SQL, executes it against the ToolJet database, and gives me the result. No manual exports required.
/2. The Write Phase: insert_row
This is where we move away from 'Chatbot' territory and into 'Agentic' territory. If an agent identifies a pattern—say, it sees a surge in failed login attempts in your logs—it shouldn't just report it. It should be able to log that event or create a support ticket directly by using insert_row. This bridges the gap between observation and record-keeping.
3. The Execution Phase: trigger_workflow
This is, in my opinion, the most important tool in this set. ToolJet is powerful because of its workflow engine—the ability to chain webhooks, run scripts, and interact with third-party APIs (Slack, SendGrid, etc.).
The trigger_workflow tool allows an AI agent to hit a webhook with a custom JSON payload. This turns the agent into an orchestrator. I can tell the agent: "We have a high-priority order in table X; trigger the fulfillment workflow for it." The agent doesn't need to know how the fulfillment works—it just knows that by calling this tool, it has initiated a complex business process.
The Security Elephant in the Room
You can't talk about giving AI agents SQL access without addressing security. If you give an LLM a query_table tool, what stops it from trying to run something destructive?
In a production-grade setup, you cannot rely on 'hope' as a strategy. This is exactly why I built Vinkius with isolated V8 sandboxes and strict governance policies. When running MCP servers that interact with sensitive databases like ToolJet, you need audit chains (HMAC) and the ability to kill an execution context immediately if it violates DLP (Data Loss Prevention) rules. \mcp-driven automation is a massive surface area increase for your infrastructure.
How to actually use it
I've always been against high-friction setups. If you have to configure OAuth callbacks and manage complex environment variables, nobody is going to use it in their daily workflow.
The setup I recommend (and what we've implemented for the ToolJet server) follows a three-step pattern:
- Subscribe to the server via Vinkius.
- Grab your connection token.
- Paste it into your Claude or Cursor config.
That's it. You shouldn't need a DevOps degree to connect your database to your IDE.
You can find the canonical configuration and documentation for this specific server here: https://vinkius.com/mcp/tooljet
Final Thoughts
We are moving toward a world where the 'UI' is increasingly becoming a secondary interface, used primarily for configuration and high-level oversight, while the primary 'interface' for handling routine operational tasks becomes the agentic toolset.
If you are still manually querying your databases to answer simple questions or triggering workflows by clicking buttons in a dashboard, you're leaving efficiency on the table. The tools are here. The protocol is stable. It's time to stop talking about AI and start actually connecting it to your data.
MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.
Top comments (0)