Build and run integrations from your AI client, over MCP

Your AI client receives operating instructions and a described tool catalog when it connects, so it works with Neblex's real building blocks instead of guessing at an API. It covers every part of an integration, from the project it lives in to the app people use:

Forms, apps and agents keep a version history, and a deleted form, app or agent goes to Trash and can be restored. Secrets are never returned to the client.

Because every part is available, an assistant can assemble a whole solution in one conversation: a project, the connections it needs, data tables seeded with reference data, tested flows, forms for the human steps, AI agents, and an app that ties them together. Each part is tested before the app that depends on it is published.

Build a flow once, such as look up a customer in PostgreSQL, find a contact in HubSpot or check an order's status in your ERP, and your AI assistant can call it in any later session. It runs the flow with the input it needs, such as an email address or an order number, and reads the result back into the conversation.

• Tested, not improvised: the assistant runs a flow you have tested and published, with its mappings, filters and data quality checks, instead of writing its own queries or API calls.
• Reaches systems behind your firewall: a lookup flow can run on the On-Prem Worker, so Claude or ChatGPT can answer from a database inside your network without that database being exposed to the internet. The flow's final output is delivered to the assistant, and a successful run's records are removed when it finishes.
• Run-only access: grant the assistant only the flows it may run. A run-only key can run its granted flows and can never create, change or publish anything.
• Every call is recorded: each run is in the run history like any other run.

Under the hood each flow you grant appears to the assistant as its own tool: it calls the tool with the input, and the flow's output comes back as the answer. A flow that outlasts the call's wait answers with its run id instead, and the assistant follows its status. Any flow can serve as a tool, from a one-step lookup to a multi-step process with approvals.

If AI assistants will build or run integrations for your team, check these points with any platform. Here is how Neblex answers each one:

An MCP gateway exposes individual application actions, such as create a ticket or look up a contact, for an assistant to call one at a time. That suits quick lookups and single actions.

An MCP integration platform lets the assistant build complete integrations: multi-step flows with mappings, deduplication and validation, tested before they go live, run on a schedule or trigger, and recorded in run history. The Neblex MCP server is the second kind, and the integrations it builds keep running without the assistant.

1. 1
   Add the endpoint: https://if.neblex.com/mcp. In Claude Code: claude mcp add --transport http neblex https://if.neblex.com/mcp
2. 2
   Authorize in the browser: sign in with two-factor authentication, then choose the scopes (operate, author, publish), the projects or flows the client may reach, and the environment.
3. 3
   Build: the client validates before saving, tests before publishing, and hands you a link whenever a person must enter a secret or approve a change.

In Claude, ChatGPT, Codex, Cursor and other clients, add https://if.neblex.com/mcp as a remote MCP server or custom connector. No API key is needed: the client signs in with OAuth. Full setup is in the MCP guide.

Tools are grouped by scope, so you decide whether a client may only run flows, may also build, or may also publish.

• Sign-in with two-factor authentication for any client that builds or publishes.
• Scoped consent: you pick the scopes, projects, flows and environment on the consent screen.
• Human approval before anything is published into a protected environment.
• Run-only keys: a static API consumer key can inspect and run its granted flows, and can never create or publish.
• Visible and revocable: connected clients are listed under API Consumers with who granted them, and Revoke cuts access at once.
• Permission-controlled: using MCP requires the Use MCP channel in a user's permission profile.
• No silent overwrites: if someone changed a flow, form or app after the assistant read it, the update is refused, and the assistant re-reads it instead of overwriting their work.
• Safe deletes: deleting checks what depends on the item first, needs the exact name to confirm, and sends flows, forms, apps, agents and connections to Trash so they can be restored. Deleting a data table erases it for good, so treat that permission with care.
• Impact before change: before a connection is changed, the assistant can list every flow and agent that uses it.

Yes. Give your AI client a workflow exported from another integration or automation platform, or the code of a script or serverless function, and ask it to rebuild it as a Neblex flow. It maps each step to a native Neblex step, test-runs the flow against your systems, and leaves it unpublished for you to review. A test runs the real steps, so point it at test systems when a flow writes data.

• Native steps instead of code: paging, retries, batching and upserts become built-in steps, so the result is readable in the visual builder.
• Problems surface on the way: rebuilding a workflow means reading every step, so the assistant reports what the original got wrong.
• Nothing goes live unreviewed: the flow stays unpublished until you publish it.

In one of our tests, a public workflow template went from 11 steps, three of them code, to 5 native steps that ran against the same API. Along the way the assistant found problems in the originals it converted: a branch that never ran, a loop that silently stopped on a failed page, and values concatenated into SQL text.

Anything your AI client builds runs in the Neblex cloud or on the Neblex On-Prem Worker, a runtime inside your own network. On the Worker, the flow executes next to your databases and file shares: the Worker connects out on port 443, opens no inbound ports, and sends the cloud run status, diagnostics, record counts and integrity receipts, not your records. The exception is what you ask to see: when an assistant calls a flow, the flow's final output goes back to the assistant.

AI agents run the same way, and their reasoning and embedding models can run inside your network too, with the agent's knowledge base in your own PostgreSQL with pgvector.

Ask in plain language, for example:

• "Build a HubSpot to Snowflake sync that removes duplicate contacts."
• "Why did last night's run fail, and what would fix it?"
• "Look up the customer with this email in our Postgres database and show their last three orders."
• "Which flows use our Salesforce connection? List them before I rotate its credentials."
• "Set up a knowledge store on our Postgres and build an agent that answers from our policy documents."
• "Load our on-premises SQL Server orders table into the warehouse every night, on the Worker."
• "Draft an AI agent that answers from our SOPs and asks a person before it acts."
• "Here is a workflow exported from our old integration platform. Rebuild it in Neblex and test it."

• Connect an AI client (MCP), Neblex Integration Fabric docs
• neblexhq/neblex-mcp, public repository
• Model Context Protocol documentation
• Neblex internal tests, 2026.

Last checked: November 5, 2026.