Build a Workflow or an App from your IDE or Agent v2

Use Builder MCP from your IDE to create integration Workflows and the backend Workflows for an App you are building. Your coding agent can work on the Flowgear logic and your local frontend together, using the Workflows' OpenAPI definition to connect the two.

For an integration, describe the systems to connect, the data to move, and when it should run. For an App, also describe what users should see and do. The agent can create HTTP-bound Workflows for those actions while building the interface in your project.

Connect your IDE

You need Site Administrator access, a Test Environment with a hostname, and a coding agent that supports remote HTTP MCP servers and OAuth.

Open MCP from the Console's main navigation. In the Builder MCP panel, follow the instructions for your coding agent. The MCP screen provides the setup instructions for your Site's Test Environment.

Once connected, use this prompt to verify the setup:

Check that Flowgear Builder MCP is working and confirm which Tenant, Site, and Environment it is connected to.

Check that the reported context is the Site and Test Environment you intend to use.

Scenario: an order integration status App

Suppose your team needs an App to see orders moving from an online store to an order management system. Operators should be able to list order details, see each order's current status as a badge, and change an order from draft to placed.

In this walkthrough, you will simulate the order data in Flowgear Key/Value storage. This lets you build and test the App before connecting real order systems. Here, placed records a change in the sample data; it does not submit an order to an external system.

You will build three Workflows:

Workflow Purpose
Generate Order Data Generate random orders and store them in Key/Value storage.
List Order Details Provide an HTTP endpoint that returns the stored orders and their statuses.
Place Order Provide an HTTP endpoint that changes one order from draft to placed.

The first Workflow supplies the data, much as an integration Workflow would collect it from a source system. The other two Workflows form the App's backend. All three use the same collection in the same Site and Environment.

Generate the order data

Give your agent this prompt:

Create a Flowgear Workflow called "Generate Order Data" in the Test Environment. Each time I run it, generate 10 random sample orders with realistic order details and a status of "draft", and store them in a dedicated Key/Value collection. Preserve any existing orders and use fictional data only.

Test and save the Workflow, then give me a link to it.

The agent uses Builder MCP to discover the available Nodes and their contracts, create the Workflow, and run it in Debug mode. It can inspect logs and repair failures before saving the tested design. Debugging this Workflow writes sample records, so repeated test runs may add more than 10 orders.

Open the returned Workflow link to review the design and its logs. The list endpoint you build next will let you check the stored order details.

If you only need an integration Workflow, you can use this same build-and-test process with your own source systems, existing Connections, and business rules. Continue below to add an App over the data.

Prepare the App project

Start with the sample App, which includes the Flowgear SDK, local development configuration, and guidance for your coding agent.

  1. Open Settings → Manage Apps in the Console.
  2. Click Download a sample App.
  3. Select the same Site and Test Environment used for the order data, then download the project.
  4. Extract the project and open it in your IDE.
  5. Run npm install in the project terminal.

Keep your agent working in this project for the remaining prompts. If you are already developing a Flowgear App, use that project and check that its development context matches Builder MCP.

Create the App's backend

Ask for the two HTTP-bound Workflows together so that they work with the same order data:

Use this project's guidance to create two backend Workflows for my App, using the sample orders from "Generate Order Data":

1. "List Order Details" should let the App list the orders and their current statuses.
2. "Place Order" should let the App change a selected order from "draft" to "placed", preserving its other details.

Test and save both Workflows in the same Test Environment, and make them available to my App. Retrieve their OpenAPI definition for the frontend and give me links to the Workflows.

The agent creates and tests the backend before binding the interface to it. Builder MCP then supplies an OpenAPI definition describing the HTTP endpoints. The agent uses this to identify the actual routes and request and response shapes, so the frontend follows the saved Workflow contracts.

Embedded Apps invoke Workflows through the Flowgear SDK. The Console makes the call on behalf of the signed-in user, with access limited by a Cookie-based API Key. The endpoints must be published, enabled, and permitted for your user in the selected Environment.

Build the order interface

Now give your agent this prompt:

Build an "Order Integration Status" App using the backend Workflows and their OpenAPI definition. Show a list of orders with useful order details and the current status as a badge.

Add a "Change status" button for draft orders that changes their status to "placed" and updates the badge. Include a Refresh button and clear feedback when data is loading or an action fails.

Follow the sample App's guidance so it works inside the Flowgear Console. Test the App and tell me how to run it locally.

Your agent now has both the frontend code and the Workflow API contracts in context. When an interface change needs different backend data, ask for the Workflow change as part of the same request. The agent can test the Workflow, refresh openapi.yml, and update the frontend to match.

Debug the App and its Workflows

The sample's local development setup embeds your locally served App in the Console. This is part of your IDE development cycle: you can edit the frontend locally and exercise its real backing Workflows without publishing a new App package for each change.

  1. Run npm run dev in the App project terminal.
  2. Open the local HTTPS tab and accept its development certificate warning.
  3. Switch to the Console debug tab that also opens, and refresh it if the App has not loaded.
  4. Confirm that the App is using the intended Site and Test Environment.
  5. Click Refresh and confirm that the sample orders appear with status badges.
  6. Click Change status on a draft order and confirm that its badge becomes placed.
  7. Refresh the list and confirm that the order remains placed.

The App is embedded in the Console, and its actions call the backend Workflows. To trace an action, open the relevant Workflow and inspect its logs. For example, a Change status click should invoke Place Order, update the stored record, and return the new status to the App.

Use the browser's developer tools to inspect frontend errors and the Workflow logs to inspect backend execution. If the embedded App is blank, first check that you accepted the local HTTPS certificate. If calls fail, check the selected Environment, endpoint availability, and Cookie-based API Key access.

Describe a reproducible failure to the agent, including the order ID, expected result, actual result, and any visible error. For example:

Clicking "Change status" on this draft order does not update its badge. Investigate the App and its backing Workflow, fix the problem, and check that the order still shows as "placed" after I refresh the list.

Identify the affected sample order when you send the prompt. The agent can use Builder MCP to inspect Workflow logs and Debug a repair while editing the frontend in your IDE. Repeat the browser action after a fix: a successful Workflow Debug run verifies the backend path, while the embedded App test verifies the complete user interaction.

Publish when ready

Once the list and status change work together, follow Publish and Assign an App to build, package, publish, and assign the App to a Site. Release the backing Workflows and configure user access for the destination Environment as well; publishing the App package is a separate operation.

To connect real order integrations later, replace the sample-data source with Workflows that read and update your order systems, and keep the App's API contracts aligned with that behavior.

See also