Artificial Intelligence is rapidly changing how applications are built and interact with external systems. As AI assistants become more capable, developers need a standardized way to connect AI models with enterprise applications, databases, APIs, and business processes.

This is where Model Context Protocol (MCP) comes into the picture.

In this article, we’ll explore what MCP is, why it matters, and how tooljet-mcp, an MCP server built specifically for ToolJet lets a coding agent like Claude Code or Codex build and maintain real ToolJet apps.

Model Context Protocol (MCP) is an open protocol that allows AI models to securely interact with external tools, applications, APIs, and data sources.

Think of MCP as a universal connector between AI models and business systems.

Instead of building custom integrations for every AI use case, MCP provides a standardized approach for exposing:

• Business APIs
• Databases
• Documents
• Enterprise systems
• Custom tools and services

to AI assistants and Large Language Models (LLMs).

Without MCP

AI → Custom Integration → Application

AI → Custom Integration → Database

AI → Custom Integration → API

Every integration requires separate development and maintenance.

With MCP

AI → MCP Server → Business Systems

A single standardized interface can expose multiple tools and data sources.

Organizations often struggle with AI integration because:

• Data is distributed across multiple systems.
• APIs have different formats.
• Security requirements vary.
• Custom integrations are expensive to maintain.

MCP solves these challenges by providing:

Standardization — AI models interact with systems using a common protocol.

Reusability — one MCP server can expose multiple capabilities.

Security — access control can be managed centrally.

Faster Development — developers spend less time building custom connectors.

MCP consists of three main components:

1. MCP Client – the AI application or assistant, e.g. Claude Code, Codex, or any other agent.

2. MCP Server – a server that exposes tools and resources. tooljet-mcp is exactly this: an MCP server that wraps ToolJet’s governed APIs so an agent can act on workspaces, apps, pages, datasource queries, ToolJet DB tables, components, layouts, and lifecycle events.

3. Tools & Resources – the actual functionality exposed to the AI, such as create_app, list_datasources, or add_components.

The flow looks like:

User

 ↓

Coding Agent (Codex, Claude Code, …)

 ↓

MCP Client

 ↓

tooljet-mcp (MCP Server)

 ↓

ToolJet APIs / Apps / ToolJet DB

Unlike a generic wrapper that guesses at configuration keys, tooljet-mcp ships with generated component and datasource catalogs, so the agent works from first-party contracts instead of trial and error. This is a deliberate design choice in the project: tools like get_component_catalog and get_datasource_query_schema exist specifically so the agent never has to hallucinate a prop name or a query shape.

Architecture

Coding Agent

     ↓

 tooljet-mcp (MCP Server)

     ↓

 ToolJet Backend API (:3000) + Postgres/PostgREST

     ↓

 Apps, Pages, Queries, ToolJet DB Tables

The MCP server sits between the agent and a running ToolJet instance (backend on :3000, frontend on :8082), authenticating with the same admin credentials a human developer would use.

1. Natural-language app scaffolding

A developer can ask an agent:

“Build me a ticket dashboard on my ToolJet DB.”

The agent lists data sources, creates the app, lints the spec, and applies it — no manual clicking through the ToolJet editor.

2. Schema-aware datasource work

Instead of guessing at a REST or SQL query shape, the agent calls get_datasource_query_schema to fetch the exact request contract (and response shape, where known) before writing a query.

3. ToolJet DB modeling

The agent can inspect existing tables with list_tables / get_table_schema, then create or evolve tables with create_tables / add_table_column, with dependency preflighting built into the batch calls.

4. Governed, auditable changes

Destructive actions – drop_table_column, drop_table, and confirmed deletes – require an explicit confirm: true, and large or billable reads require explicit approval. This keeps an autonomous agent from silently destroying data.

5. Form and page generation

generate_form_schema builds a schema-driven create/edit form directly from a ToolJet DB table’s structure, and add_pages / add_components place it on a page.

Setting up ToolJet MCP involves four main steps:

1. Create a ToolJet Personal Access Token.
2. Configure the MCP environment.
3. Install ToolJet MCP in your coding agent.
4. Verify the connection and start building.

Before connecting an AI coding agent to ToolJet, create a Personal Access Token (PAT).

In ToolJet, navigate to:

Profile Settings → Personal access tokens

Create a new token.

Make sure you create the token inside the workspace you want your coding agent to work with.

A PAT is tied to the workspace in which it was created. This determines which workspace the agent can access and modify.

Once generated, the token will begin with:

tj_pat_

For example:

tj_pat_xxxxxxxxxxxxxxxxx

Copy the token immediately and store it securely.

ToolJet will not display the complete token again after you leave the page.

The authentication flow looks like this:

User

  ↓

Creates Personal Access Token

  ↓

PAT is configured in MCP Client

  ↓

Coding Agent

  ↓

tooljet-mcp

  ↓

PAT sent to ToolJet

  ↓

ToolJet validates PAT

  ↓

Workspace access is granted

  ↓

Agent executes ToolJet operations

The important part is that the token determines the workspace and permissions available to the coding agent.

For example:

Developer

   ↓

Creates PAT in Workspace A

   ↓

tj_pat_xxxxx

   ↓

Configures ToolJet MCP

   ↓

Claude Code / Codex

   ↓

tooljet-mcp

   ↓

Workspace A

   ↓

Apps / Queries / ToolJet DB / Components

If the developer wants the coding agent to work with another workspace, a PAT should be created for that workspace instead.

ToolJet MCP reads its configuration from environment variables available to the coding agent when it starts.

The primary configuration values are:

Variable	Required	Description
TOOLJET_PAT	Yes	Personal Access Token created in Step 1
TOOLJET_URL	Yes	URL of your ToolJet instance
TOOLJET_APP_URL	No	URL used when returning ToolJet application links

For a deployed ToolJet instance:

export TOOLJET_PAT=”tj_pat_your_token_here”

export TOOLJET_URL=”https://your-tooljet-instance.com”

export TOOLJET_APP_URL=”https://your-tooljet-instance.com”

For a local ToolJet installation using the default ports:

export TOOLJET_PAT=”tj_pat_your_token_here”

export TOOLJET_URL=”http://localhost:3000″

export TOOLJET_APP_URL=”http://localhost:8082″

TOOLJET_URL represents the ToolJet instance that the MCP server communicates with.

TOOLJET_APP_URL is used when the MCP server generates links that allow you to open an application in ToolJet.

When working with a deployed ToolJet instance, use https:// for your ToolJet URL because the PAT is sent to the configured ToolJet instance when MCP tools are invoked.

ToolJet MCP can be connected to coding agents such as Claude Code, Codex, or another MCP-compatible client.

You should configure the environment variables before starting your coding agent so that the MCP server can access them when it launches.

ToolJet MCP can be installed directly as a Claude Code plugin:

/plugin install github:ToolJet/tooljet-mcp

Alternatively, you can install it through the plugin marketplace.

First add the ToolJet marketplace:

/plugin marketplace add ToolJet/tooljet-mcp

Then install the ToolJet App Builder plugin:

/plugin install tooljet-app-builder@tooljet

Restart Claude Code after installation.

The plugin registers both the ToolJet MCP server and the companion ToolJet app-building skill.

Your environment should already contain:

export TOOLJET_PAT=”tj_pat_your_token_here”

export TOOLJET_URL=”https://your-tooljet-instance.com”

export TOOLJET_APP_URL=”https://your-tooljet-instance.com”

before Claude Code is launched.

For Codex, add the ToolJet marketplace:

codex plugin marketplace add ToolJet/tooljet-mcp –ref main

Then install the ToolJet App Builder plugin:

codex plugin add tooljet-app-builder@tooljet

The MCP server will use the same environment variables:

export TOOLJET_PAT=”tj_pat_your_token_here”

export TOOLJET_URL=”https://your-tooljet-instance.com”

export TOOLJET_APP_URL=”https://your-tooljet-instance.com”

Any MCP client capable of launching a stdio MCP server can connect to ToolJet MCP.

Clone the repository:

git clone https://github.com/ToolJet/tooljet-mcp.git

Then register the MCP server with your client.

A configuration can look like:

{

  “mcpServers”: {

    “tooljet”: {

      “command”: “node”,

      “args”: [

        “/absolute/path/to/tooljet-mcp/bundle/index.js”

      ],

      “env”: {

        “TOOLJET_PAT”: “tj_pat_your_token_here”,

        “TOOLJET_URL”: “https://your-tooljet-instance.com”,

        “TOOLJET_APP_URL”: “https://your-tooljet-instance.com”

      }

    }

  }

}

Replace:

/absolute/path/to/tooljet-mcp/

with the actual location where you cloned the repository.

Also replace:

tj_pat_your_token_here

with the PAT created earlier.

For clients that support skills, the skill/ directory from the repository should also be loaded.

The tools themselves will still work without the companion skill, but the skill gives the coding agent additional context about ToolJet’s app model and recommended build workflow.

After configuring ToolJet MCP, restart your coding agent so it receives the configured environment variables.

Then ask:

“List my ToolJet workspaces.”

The coding agent should invoke the appropriate ToolJet MCP tools.

If authentication is working, it should return the workspace associated with the PAT.

The complete connection flow now looks like:

PAT created in ToolJet

        ↓

TOOLJET_PAT

        ↓

MCP Client Configuration

        ↓

Claude Code / Codex

        ↓

tooljet-mcp

        ↓

ToolJet Authentication

        ↓

Workspace

        ↓

ToolJet MCP Tools

You can then test the complete app-building flow with:

“Build me a ticket dashboard on my ToolJet DB.”

The agent can inspect your data sources, create the app, add queries, add components, validate the resulting application, and return ToolJet links for editing and testing it.

Prompt:

Build me a tickets dashboard on my ToolJet DB.

Agent flow:

list_datasources → create_app → lint_app_spec → apply_app_phase

with add_queries / add_components used for later targeted additions.

create_app returns an editor link for following the build live and a viewer link for testing the completed page, so the developer can watch the agent work and immediately try the result.

Tool	Purpose
list_workspaces() / use_workspace(workspace_id)	Inspect or switch the active ToolJet workspace
create_app(name)	New app + version + Home page, with editor/viewer links
list_datasources(version_id)	Workspace sources available to apps, each with a settings URL
get_datasource_query_schema(…)	Fetch exact request contracts and response shapes
list_tables() / get_table_schema(table_name)	Inspect ToolJet DB tables and relationships
create_tables(…) / add_table_column(…)	Create or evolve ToolJet DB tables, with dependency preflighting
insert_rows_batch(…)	Insert-only seed writes for ToolJet DB tables
drop_table_column(…, confirm:true) / drop_table(…, confirm:true)	Explicitly confirmed destructive cleanup
get_component_catalog(…)	Component palette or selective contracts, including authoring hints
generate_form_schema(…)	Generate a schema-driven create/edit Form from a table
lint_app_spec(…) / apply_app_phase(…) / validate_app(app_id)	Dry-run, apply, then statically validate persisted state
add_pages(…) / update_pages(…)	Add or restyle pages, including the Home page
add_queries(…)	Create datasource queries
add_components(…) / add_component_batches(…)	Place components, including atomic parent/child batches
add_events(…) / add_query_lifecycles(…)	Add interactions or expand mutation success/failure flows

Faster AI integration – no need to build AI-specific integrations repeatedly; the MCP server already speaks ToolJet’s API.

Contract-accurate, not guessed – generated component and datasource catalogs mean the agent works from real schemas instead of hallucinated configuration keys.

Reusable architecture – the same server supports Codex, Claude Code, or any other MCP client.

Governed by design – destructive operations require explicit confirmation, and large/billable reads require explicit approval.

Before implementing MCP with ToolJet in a real environment:

Security – credentials are read from environment variables since a plugin can’t prompt for secrets; keep them out of source control.

Data Privacy – limit which workspaces and data sources the agent’s credentials can reach.

Performance – batch tools exist partly to reduce round trips; large/billable reads still require explicit approval.

Governance – lint_app_spec and validate_app give a dry-run and a static-validation step before and after changes land, which is worth keeping in any workflow rather than skipping to save time.

Model Context Protocol (MCP) is emerging as a standard way for AI systems to interact with enterprise applications, and tooljet-mcp is a concrete, working example for low-code development: a coding agent can list workspaces, create apps, model ToolJet DB tables, wire up queries and components, and validate the result — all through governed tools backed by real API contracts rather than guesswork.

By exposing ToolJet’s REST APIs, datasource queries, and ToolJet DB through an MCP server, teams can let an agent build and maintain apps directly, while still keeping destructive actions behind explicit confirmation.