2.5 Connections

Connections is a catalogue of 45 applications an agent can work across — GitHub and GitLab, Slack, Lark, DingTalk and WeCom, Notion, Figma, Sentry, Kubernetes, MongoDB and the SQL databases, mail over IMAP and SMTP, Stripe and Alipay, Firecrawl and Tavily, the Amap and Baidu map services, a browser, object storage and the cloud drives rclone reaches, a folder on this machine, and more. Connect one here, tick the agents that should have it, and Gateway writes it into each of their configuration files.

A connection is an MCP server with its credential kept in Gateway rather than in every agent's file.

Connecting an applicationCopy Anchor Link

1. Pick the application. The catalogue is grouped — Office, Documents, Development, Professional services, Mail, Storage, Life — with All as the default.
2. Fill in what it needs. Each field says where the value comes from: a GitHub personal access token from Settings → Developer settings, a Notion internal integration you then share pages with, a Lark self-built app's ID and secret, an Amap web service key rather than the one for apps. Some servers — a browser, a folder — need no credential at all, only the directory or target you name.
3. Install into: tick the agents. Unticking one later takes the server back out of it.
4. Connect.

The card then says Connected, and in how many agents.

Connecting also tests the application straight away, in the background, which is what gives it a switch per tool — see below.

Disconnect removes it from every agent it was written into and forgets the credential.

Signing in instead of pasting a tokenCopy Anchor Link

Some applications are connected by approving them rather than by copying a key: GitHub (OAuth app) and Lark (sign-in) are the two in the catalogue today. The Lark one is worth the extra step — what the agent may reach becomes what you may reach, rather than everything the application was approved for.

You register the application yourself, on the vendor's own platform:

1. The dialog shows a callback URL. Copy it exactly.
2. Create an OAuth app on the vendor's side and give it that callback URL.
3. Paste its Client ID and Client secret into the dialog.
4. Authorize. A tab opens on the vendor's site; approve it there and come back.

The grant then lives in your own organisation, with its own audit trail, and no secret of Gateway's is involved anywhere. Gateway renews the token by itself when it is about to expire, at the moment a session needs it.

Testing one, and what the test is forCopy Anchor Link

Run test starts the application's server, asks what tools it offers, and stops it again. Two things come of that:

• You find out the credential works before an agent tries to use it. A failure quotes what the server itself said, so a wrong key or an unreachable folder reads as that rather than as a timeout.
• The tool list it brings back becomes one permission switch per tool. Until a connection has been tested, it is governed by a single switch for the whole application; afterwards you can leave the application on and take one tool away, or leave it off and allow just one. See 4.1 Permissions.

The first run of a server that is installed from npm downloads it, which is slow and is not a failure.

Why the credential is not in the agent's fileCopy Anchor Link

What Gateway writes into an agent's configuration is Gateway itself, as the server to run, with the name of the connection as its argument. When the agent starts that server, Gateway fetches the credential over loopback for the life of that one session.

So:

• The token is not sitting in ~/.claude.json, ~/.codex/config.toml or the equivalent for eight other agents.
• Changing the credential once changes it for every agent that has the connection.
• Everything the agent sends passes through Gateway, so a tool call can be checked against that agent's permissions before it runs, and recorded after — connector traffic is held to the same rules as the rest of the agent's tools.

Gateway rewrites those entries when it moves or changes port, so a connection does not quietly break after an update.

The trade: an agent reaches a connected application through Gateway, so a connection works only while Gateway is running. Stop Gateway and those servers fail to start in the agent, which is what the note under Install into says before you tick anything.

Connections travel in a snapshot like providers do, credentials included when the snapshot carries secrets. Restoring one onto another machine writes the entries again with that machine's port and program.

Which agents can take oneCopy Anchor Link

Only agents whose MCP configuration format Gateway knows how to write. If the page says no agent was found, this machine has none installed — the MCP column of the table in the README is the list.

Connections against Skills, MCP & PromptsCopy Anchor Link

Next: 2.6 Chat.