Connect an app with MCP

The development desktop build can call tools from remote MCP servers during a workflow run. You connect the server once on MCP Connections, then refer to its local ID from any .aether file. The published release may not have this page yet; check the download page for the current build.

Find and connect a server

1. Open MCP Connections from the activity bar. Search the public MCP Registry or choose Add server address if you already have a remote Streamable HTTP URL.
2. Review the address and the server’s requested access. Enter a display name; Bandura suggests a connection ID you can change. Choose the credential the server requires: no token, a bearer token, or a custom header value. Save the connection.
3. Choose Check all to see which saved apps currently expose tools and which need attention. This makes up to three checks at a time; Stop checking prevents further checks from starting. Select one app and choose Check tools to inspect its names and input schemas. The list summarizes top-level inputs, marks required ones, and can be searched by tool name, description, or input name on servers with large catalogs.

If you have more than three saved apps, search them by name, ID, or server address. After checking, filter the list to ready apps, apps that need attention, or apps you have not checked yet. The counts above the list summarize the current session. The list shows when each check completed during this session. Clear the saved-app search in one click when you are done.

For a saved app, Copy ID copies its workflow reference. Copy setup manifest copies its ID, server address, and authentication shape without the saved credential or URL query parameters, so another user can create their own local connection. Review the address before sharing; a path can still contain private data. After inspecting tools, you can sort them by name, search input types or enum choices, and copy an open tool’s full schema as JSON.

Each check sends a read-only MCP tools/list request using the saved credential; it never runs a tool. The status distinguishes available tools, an empty tool list, missing credentials, refused access, an unreachable server, and likely transport incompatibility. Bandura shows general guidance rather than a raw server error, which might include a secret. Statuses reflect the last check in this open app session and are cleared when you change a connection. Recheck before relying on it: a successful list does not guarantee that a later tools/call is permitted or that the server’s data is correct. A Registry result alone does not authorize your account or confirm the server works.

The credential is stored on this device and is not written into the workflow file. A teammate opening the file must add their own connection with the same ID. Changing the server address or authentication method requires a new credential. OAuth sign-in and local stdio servers are not supported yet.

Add one tool to a workflow

Open a .aether workflow, return to MCP Connections, and choose Add to open workflow beside a checked tool. Bandura inserts it after the main chain, selects the new node, and opens its Tool tab with the inspected inputs ready to fill. Save the workflow and run it when its required inputs are set. Repeated uses of the same tool get distinct node IDs and output variables.

Alternatively, choose Copy YAML step and paste it into a workflow’s nodes list. Connect it with start or next and fill the required inputs from the tool’s Input schema. The copied step includes the saved connection ID and exact tool name, but no credential or guessed arguments. Change its suggested node ID or output name if either already exists in the workflow.

You can also select an mcp-tool node in the graph, open its Tool tab, choose a saved app, and inspect its current tools. Use this tool updates the node’s connection ID and exact tool name. Existing arguments stay in the node so you can review them in its Node tab; required inputs are listed in the Tool tab. Simple string, number, boolean, and named-choice inputs can be filled in that tab. Use YAML for nested inputs or dynamic expressions.

For example, if your server exposes a search_customer tool with an email argument, the completed step could be:

- id: call_search_customer
  type: mcp-tool
  config:
    connection: customer-app
    tool: search_customer
    arguments:
      email: "${{ variables.email }}"
    output: customer_result
  next: check_customer

This is an illustration: the exact tool name and arguments come from your server. When this step runs, Bandura first checks the server’s current tool list and validates arguments against the advertised input schema. A missing required value or wrong type fails the node before the tools/call request. The server still decides whether the call is valid, including for schema features Bandura cannot check locally. On success, Bandura stores structuredContent at variables.customer_result if the server returns it, or its content blocks otherwise. Add an assertion or condition to check the result before another action. A connected tool may read or change data with the permissions of the credential you supplied.

Run and share

Run the flow in the desktop app and inspect the node result and run history. Commit or send the .aether file and explain which connection IDs, tools, and input variables the recipient must provide. Do not send the credential with the file. If the recipient cannot connect to the same server, the MCP step will fail rather than silently skipping it.

The desktop’s saved connection IDs are not available to the CLI or MCP server yet. For headless runs, use a direct serverUrl and an environment-backed header as described in the mcp-tool reference.