Connections

Everything your automations authenticate against, in one place. The page manages two different kinds of record: connections, the saved credentials a trigger or an action uses to reach an external system, and MCP servers, the tool sources an AI agent draws from as it works. They share this page because they are created, edited, and selected the same way—but they are separate things, and the difference matters when you set one up. For the concept, and for the table of which nodes each connection type powers, see Connections.

The layout

The left rail holds two lists, stacked:

List	What it holds
Connections	Every connection, of every type, each with its type's icon. A connection that is not currently authenticated carries a warning triangle—which is where to look when steps that used to work start failing. Archived connections stay in this list.
MCP Servers	Every live MCP server, listed by name. Unlike the connections above, an archived server drops out of this list.

Selecting an entry from either list opens its form in the panel on the right. With nothing selected, the panel invites you to create one or pick one. Selecting an entry that is not available—one that cannot be reached, or one that no longer exists—says only that the record was not found, without saying which.

Creating one

Each list has its own create control above it, and both work the same way: choose a type from the dropdown, then click New. The dropdown is searchable, so you can type a few letters of the type name rather than scrolling. When only one type is available, the dropdown is replaced by a single button naming it.

Which types appear depends on what the deployment has installed. If no connection types are available at all, the list says so in place of the control.

The new record opens as an empty form. What it asks for depends on the type, and the setup each one needs—an application registered with the provider, a key issued by an account holder, a permission granted on the far side—is covered on that integration's page under Integrations.

Authorizing

Connections authenticate in one of two shapes, and the form tells you which:

• Authorize with the provider. The form shows a Connect button. It sends you to the provider to sign in and grant access, then returns you with the connection live. A Disconnect action tears that authorization down again.
• Enter a credential. The form holds a token, key, or client secret you paste in. It becomes usable as soon as those fields are saved.

Once authorized, the form shows a Connection active note, usually with the identity the connection acts as. That identity is worth reading: everything automations do through this connection runs as that account, with exactly its permissions.

MCP servers authorize the same way. A server can use OAuth, a bearer token, an API key, or no authentication at all, depending on its type—and it authenticates against its own endpoint, separately from any connection pointing at the same system. A connection to a system does not authenticate an agent to that system's tool endpoint. A server's name is also how its tools are identified to an agent, so keep it short and recognizable.

Editing

Selecting an entry opens the standard edit form, with Save at the bottom. Editing is live: a step's reference to a connection is never a snapshot, so rotating a token here fixes every step that depended on it, with nothing to republish.

If a save fails validation, the form comes back with your values still on it and the error shown—nothing is lost. An MCP server's name has to be unique, and the form refuses a duplicate rather than saving it.

Archiving and restoring

Archiving a connection is how you stop using it. Archiving takes effect immediately, and it means what it says: from the automations' point of view the connection is gone. Incoming events from a system whose connection is archived are refused from that moment, rather than continuing to run automations for however long the connection sits archived. The form of an archived connection shows an Archived banner in place of its connection status.

Restoring recovers the settings, not the live binding. It is a convenience—a way to get the previous configuration back without retyping it—rather than an undo. A restored connection serves actions again, but a trigger that listens for events from that system stays silent until its automation is saved again, which is what re-registers it with the far side. Open the automation and save it.

Deleting a connection outright also cleans up the registrations it made, so the far side stops sending events it has nowhere to deliver.

Where to go next

• Connections—what a connection is, what it carries into a run, and which nodes each connection type powers.
• Integrations—per-system setup, field by field.
• AI agents and models—how a provider account here becomes the model an AI step runs on.
• Agents—where an agent's tools are chosen from the MCP servers set up here.