MCP Workflow Builder: Connect APIs and Databases to AI Visually

A workflow tool is an MCP tool you build on a canvas instead of in a code editor. You place steps, connect them from left to right and fill in a few fields. When you save, MCPCore compiles the workflow and runs it in the same isolated sandbox as code tools. To Claude, Codex or Cursor, it looks exactly like any other tool: a name, a description, typed parameters and a result.

This guide goes through everything the workflow builder can do, with examples you can copy. If you are new to MCP, start with How to Build an MCP Server Without Code first.

The Building Blocks

Every workflow begins with a Start step and ends with at least one Return step. In between, you use these steps:

Step	Group	Use it to
Database	Data	Open a PostgreSQL, MySQL or SQL Server connection from your secrets
Query	Data	Run parameterized SQL on that connection
HTTP Request	Integrations	Call an HTTPS API with headers, query parameters and a JSON body
Transform	Logic	Build a new object from fields of earlier steps
Condition	Logic	Branch on a comparison, such as "is empty" or "is greater than"
For Each	Logic	Run a group of steps once for every item in a list
Static Data	Data	Return or reuse fixed JSON
Return	Output	Send the final value back to the AI client

A step runs only after every step it depends on has finished, and a Condition skips the steps on the branch it did not take. The first Return that runs ends the tool.

Variables: How Data Moves Between Steps

Any text field can contain variables in double curly braces. There are five roots:

Variable	Meaning	Example
{{params.name}}	A parameter the AI passed	{{params.email}}
{{env.KEY}}	An encrypted secret	{{env.API_TOKEN}}
{{nodes.id.output}}	The output of an earlier step	{{nodes.query_1.output[0].name}}
{{loop.item}}	The current item inside a For Each	{{loop.item.id}}
{{nodes.id.error}}	Why a step failed, on its error branch	{{nodes.http_request_1.error.message}}

Two details save a lot of debugging:

• A whole-field variable keeps its type. A field containing only {{nodes.query_1.output}} passes the real array, not a string. Mixed text like Hello {{params.name}} becomes text.
• Missing values do not throw. If output[0] does not exist, the variable is simply empty, which you can catch with a Condition step's "is empty" check.

The HTTP Request step also has a Query parameters list. Rows whose value ends up empty are left out of the URL, so optional parameters the AI does not send never produce ?status=&limit=.

Example 1: A Safe Database Lookup

Start → Database → Query → Condition → Transform → Return
                                     ↘ Return {"found": false}

The Query step uses ? placeholders and a binding list:

SELECT name, plan, created_at FROM customers WHERE email = ? LIMIT 1

with the binding {{params.email}}. Bindings are always sent separately from the SQL text, so the tool is immune to SQL injection even if the AI passes something hostile. The Condition checks {{nodes.query_1.output}} with "is empty" and sends the run to a friendly {"found": false} instead of an error.

Example 2: Loop Over a List With For Each

Many useful tools work on lists: enrich every order, check every repository, summarize every ticket. The For Each step runs the steps on its each output once per item, then continues on its done output.

Start → HTTP Request (get users) → For Each
          each → HTTP Request (posts?userId={{loop.item.id}}) → Transform
          done → Return {{nodes.loop_1.output}}

The output of the For Each step is a list with one entry per item: the result of the last step in the loop body. A few rules keep loops predictable:

• The loop body must end in a single step. If you branch inside it, merge the branches with a Transform.
• Return, Database and For Each steps cannot sit inside a body, so loops cannot be nested. Open the database connection before the loop.
• Items run one after another, so an external API never receives a burst of parallel requests.

A For Each step can only walk through a list. It never repeats on a condition, so it cannot loop forever. Each run is also capped at 1,000 executed steps and 100 HTTP and database calls, and a single For Each processes at most 200 items (50 by default).

Example 3: Handle Errors Instead of Failing

By default, a failing HTTP Request, Database or Query step stops the tool and returns the error to the AI. That is often the right behavior, but sometimes you want the tool to answer gracefully instead. Each of those steps has an Errors stage with two settings.

Retries (HTTP Request and Database):

Setting	Value
Retries	0 to 3
Waits	0.5 s, 1 s, then 2 s, at most 4 s per step
HTTP retries on	Network errors, timeouts, 429 and 5xx responses
Never retried	Other 4xx responses such as 400, 401 or 404

A Retry-After header on a 429 response is respected, up to two seconds.

When this step fails: choose Continue on the error branch and the step grows a red error output. Connect it to the steps that should run instead:

HTTP Request (GET /orders/{{params.id}})
   default → Return {{nodes.http_request_1.output}}
   error   → Return {"found": false, "reason": "{{nodes.http_request_1.error.message}}"}

Retries always run first; the error branch only takes over once they are used up. Query steps never retry, because a write query could run twice.

Start From a Template or From AI

You rarely start from an empty canvas. The template gallery has six ready-made workflows, including a parameterized database query, an API call with a condition, and a For Each loop that enriches a list. Each one loads its steps, tool name and parameters.

If no template fits, describe the tool in plain words and let the AI build the workflow. It follows the same rules you do: https:// only, SQL with bindings, secrets by name. If the first result has validation problems, MCPCore asks the model once more to fix them, and anything left is marked with a red border on the canvas.

Test Every Step

Click Run, fill in test values and watch the canvas:

Step looks	Meaning
Blinking blue	Running
Green	Finished successfully
Red with a message	Failed
Unchanged	Skipped, for example on the other branch

Inside a For Each loop, the step shows its progress, such as Item 3 of 10, and you can page through the output of every item in the inspector. Retries appear in the log, for example ↻ Get order failed, retry 1 of 3.

The editor also validates while you build. A step with a problem gets a red border with a clear message, such as "Connect the error output or choose Stop the tool", and Run stays disabled until every issue is fixed.

Ship Without Breaking Anything

Saving a workflow makes it live on your MCP server's endpoint right away. For changes to tools people already use:

1. Click Save draft to keep your edits away from live traffic.
2. Open History to compare the draft with the live version. Added, removed and changed steps are listed with the old and new value of every setting.
3. Click Publish draft when it looks right, or restore any earlier version in one click.

FAQ

What is an MCP workflow builder?

It is a visual editor for building MCP tools by connecting steps instead of writing code. The finished workflow runs as a normal MCP tool that any AI client can call.

Can a workflow loop forever or overload my API?

No. A For Each step only walks through a finite list, items run one at a time, and every run is capped at 1,000 steps and 100 HTTP and database calls, retries included.

Is the workflow builder safe for databases?

Yes. Credentials come from encrypted secrets, and values from the AI are always passed to the database as query bindings rather than inserted into SQL text.

When should I use code instead?

When you need complex calculations, nested loops or a library the steps cannot express. Code tools and workflow tools can live side by side on the same server.

Want to try it? Start free on MCPCore or see the full step reference in the docs.