Context & MCP

Context is the library your Agents are equipped from. MCP connections give an Agent tools — a server it can call out to — and equipping one packages it straight into the Agent's compiled artifact. The same connections also back a Workflow's tool steps, which call one of a connection's tools directly, no Agent involved. Skills are covered separately — see Skills — this page is about connections: adding them, their credentials, and how their health and tools surface.

Workspace and personal scope

The Context page opens on a Workspace | Personal segmented control. Workspace connections are shared with everyone in the workspace — "Connections and skills available to everyone in this workspace" — and mutating one requires the owner or admin role. Personal connections are private to you and follow you across every workspace you belong to, and you can always fully edit your own. One scope rule matters for pipelines: a Workflow's tool step can only use workspace connections — unattended runs execute on workspace authority, never a member's personal credential — so publishing a Workflow with a tool step on a personal connection is rejected.

Adding a connection

The Add connection dialog offers three lanes.

Catalog renders entirely from a checked-in list — no network call — as a Featured row plus tiles grouped by category (Productivity, Project management, Developer tools, Data, Communication, Commerce, Other). Each tile shows a monogram, a title, a one-line description, and an auth-type hint: No auth, OAuth, or API key. A no-auth recipe installs on one click. A secret-based recipe (bearer token or headers) opens a short credentials form with the note "Stored encrypted and sent to the server on your behalf. You will not see these values again." An OAuth recipe opens the consent popup the instant you click — synchronously, so browsers don't block it as an unsolicited popup.

The catalog grows over time; as of writing it holds nine entries:

Community search replaces the browse view the moment you start typing. Catalog matches pin above a "Community" group of results pulled from a Meilisearch mirror of the official MCP registry, each carrying a "Verified" badge for verified publishers and a lock icon when credentials are required. If Meilisearch is unconfigured or down, the lane degrades in place — "Community search is unavailable right now. Curated connectors and custom servers still work." — rather than blocking the dialog. Whatever you install from this lane is re-verified against the live official registry at install time; the mirror is search convenience only, never the trust source.

Custom URL is bring-your-own: a name, the server URL, an optional description, and an auth mode of None, Bearer, or Headers (repeatable name/value rows, values password-masked as you type).

The connection detail view

Opening a connection shows its name and slug, transport, live health, cached tool list, and a Test connection button, alongside the same write-once credential fields the add flow used — editing them replaces the stored value, and you never see what was there before. Deleting is blocked while an Agent still references the connection: "The agents below still use this connection (in their draft or a published version). Detach it from each agent's context first, then remove it," with the referencing Agents listed by name. A Workflow's tool step doesn't block deletion the same way — the published Workflow instead gains a staleness warning, and that step fails at run time until the Workflow is fixed and republished.

Health

Every connection carries one of five health states, shown as a dot plus label:

auth_required and auth_error are easy to conflate but mean opposite things — one is missing credentials, the other is credentials that didn't work. Probes run automatically after you create or install a connection with static credentials, after OAuth consent completes, and again whenever you open a connection's detail view and its last check is more than 15 minutes old, plus on demand via Test connection. A degraded or unhealthy connection never blocks publishing on its own — only a connection you've explicitly disabled, while still attached to an Agent, does that.

The tool filter and approval policy

A successful probe caches the server's tool list, and that cache drives two separate controls on the connection. The tool filter is a three-way switch — All tools, an allow-list, or a block-list — with checkboxes over the cached names plus free-text entry for anything the cache doesn't know; without a cache, it's free-text only, with a hint to run Test connection first. The filter belongs to the connection, not the Agent, so every Agent equipped with it sees the same filtered set — and it binds a Workflow's tool steps too: a filtered-out tool fails the step rather than running.

Approval policy is a separate, additional control: a default decision — Never — auto-allow, Once per session, or Always ask — plus per-tool overrides from the same cached list. The filter decides what an Agent can even see; approval policy decides whether a visible tool's call needs your sign-off before it runs.

Equipping an Agent

Attaching a connection in the agent editor's Context section pulls it, credentials and all, into what gets compiled when the Agent publishes — the compiled artifact carries the connection's identity and its tool filter, not a live reference back to this page. An OAuth connection's access token is the exception: it is never baked into the artifact, and is fetched fresh from the platform only at the moment a tool call needs it. See Security for the full trust model, and Equip an Agent for the walkthrough.

If a connection stops resolving — deleted, or disabled while still attached — see Troubleshooting.