Connectors

Connectors extend Strata to outside tools your organization already runs — GitHub, Datadog, Notion, Stripe, Snowflake and dozens more — over the open Model Context Protocol (MCP). An admin adds a connector once; each member turns on the ones they want; and the AI can then call that tool's own actions mid-answer, the same way it calls a first-party extension.

Connectors vs. extensions

Strata's deep integrations — SQL Server, OneDrive, Outlook, Atlassian, Teams — are first-party. Each is built against its vendor's own API because it needs things a generic tool bus cannot express: org service-account modes, attachment extraction, approval gates on a send, retention rules, and reach beyond chat into Teams, scheduled agents and the public API. Those stay first-party.

Connectors are for the long tail beside them: the internal server someone stood up, a vendor's read-only catalog, a niche public tool. A connector speaks MCP, so anything that publishes a remote MCP endpoint can be added without Strata shipping code for it — and it still answers the question that matters most, whose account it calls as: an admin chooses per connector between one shared sign-in and each member signing in as themselves.

The connector catalog

When an admin opens Add connector, they see a curated catalog rather than an empty address box. Picking a tile fills in the server address, the transport and the shape of the credential, and explains where that credential comes from. Every tile in the catalog was dialed live by Kronisys and carries a Verified by Strata badge; a server an admin types in by hand works too, but nobody at Kronisys checked it, so it shows no badge.

The catalog holds 62 connectors today, grouped by what a company needs it for:

Note

The catalog lists only servers Strata can actually reach with the credentials it supports. Some well-known servers accept only a sign-in flow Strata has not implemented for them, or publish no discoverable connection metadata — those are deliberately left out rather than listed as tiles that could only ever fail at connect time.

An admin can always add a server that is not in the catalog: choose Set one up manually, give it an id, paste its https address, pick the transport, and supply a credential. The catalog can be searched and narrowed to one category, and a connector your organization already has is shown as Added.

How an admin adds a connector

Managing connectors requires the Manage org settings permission. Open Organization > Connectors (/admin/connectors).

1. Add connector. Pick a catalog tile or choose to add one by hand.
2. Set the id. Lower-case letters, numbers and hyphens (2–32 characters). It cannot be changed later — its tools are named mcp__<id>__<tool> and permissions refer to it as mcp:<id>, so renaming it would silently break both. To rename, delete and re-add.
3. Confirm the address and transport. Connectors must use https. Two transports are supported: Streamable HTTP (the current MCP transport) and SSE (the older two-endpoint style many public servers still speak). A catalog tile fills both in for you.
4. Supply the credential. Four kinds:
   • None — a public server that takes no credential.
   • Bearer token — a token sent as Authorization: Bearer ….
   • Custom header — a token sent under a header name you specify, for servers that use their own scheme (for example Sentry's Sentry-Bearer or PagerDuty's Token token=…).
   • Sign in (OAuth) — press Connect and the vendor's own consent screen mints the credential. Strata never sees a password, and the token it receives is encrypted at rest. The catalog tile's instructions say which kind a given server needs.
5. Test connection. Strata connects, lists the server's tools, and caches them. The result is shown beside the button: how many tools it found, or the server's own error so you can fix the address or credential. (A few servers only check a credential when a tool actually runs, so treat a green test as "reachable", not "the token is definitely right".)
6. Enable it. Available to members, under Who can use it in the connector's form, is on for a new connector. An enabled connector becomes available to members whose role allows it; it is still off for each member until they turn it on for themselves. You can also turn a connector on or off later with the switch in the On column of its row, without opening it; an Off connector keeps its settings and is simply not offered.

The connector's form (open it from Add connector, or click its row) is laid out in four groups: Connection (name, id, address, transport, authentication), Sign-in or Credential, Tools and permissions, and Who can use it. Three more per-connector controls:

• Each member signs in with their own account — see Whose account a connector uses below. Sign-in (OAuth) connectors only.
• Let this connector make changes — off by default. See Read-only by default below.
• Tools — grouped into Read-only tools and Tools that make changes, each group with one choice that sets all of its tools (it reads Mixed when they differ), and a choice for each tool the last test found: Allow (the AI uses it without asking), Ask first (the member approves each use; see Ask first below), or Blocked (never offered). A tool that makes changes is Ask first until you choose otherwise, and any other tool is Allow. A tool counts as making changes when its server marks it destructive, or, on a connector allowed to make changes, when its server has not marked it read-only. With nothing blocked, the connector follows the server, and anything it adds later is offered too, on its default. Turn all off blocks every tool, and Turn all on puts every blocked tool back on its default. A tool the server marks as making changes stays withheld while the connector may not make changes, and is not counted as offered.

Key

With one shared sign-in, everyone who uses the connector acts as the single account the admin connected, and anything it creates is created as that account. Connect with an account whose access you are content to lend to every member the connector reaches — a scoped or read-only service account, not a global admin — and prefer a read-only credential wherever the vendor offers one. With each member signs in, nothing is shared: Strata sees exactly what the asking member's own account can see, and the vendor's own permissions do the bounding.

Making sure a connector actually reaches someone

A connector can be enabled and still reach nobody: a role saved while the role form showed connectors records which connectors it grants, so a connector added after that is withheld from members on that role until someone ticks it there. (A role list saved before your organization had any connector names none, so it has no opinion about connectors and withholds none, unless nothing at all was ticked on it: a role saved with no extension ticked grants no connector.) The Who can use it column tells you, per connector, whether All roles grant it, how many do (3 of 7 roles, with the first few named), or that Nobody yet can use it. It counts a role saved with nothing ticked as withholding every connector, the same rule chat applies. Grant it in Roles under "Nobody yet" opens the Roles page, and its tooltip names the roles that withhold it, so you can tick it on for the roles that need it. See Roles and permissions.

The Status column says what state each connector is in: On (with when it last answered), Off (paused, not broken), Error (the last check failed, with the server's reason), or Needs a key / Needs sign-in (turned on, but missing the credential it needs, so it is not offered to anyone yet; it keeps saying so after a failed check, with the server's reason underneath). The Tools column separates "not tested yet" from "0 tools found", and after a failed check shows only the last known count.

The page, the catalog and the connector's form are drawn in the language you chose in Settings: the columns, each connector's status, tools and who can use it (the roles named and separated the way your language separates a list), Check all and what it found, the menus, the catalog's search and its seven categories, the form with its help and the choice for each tool, and the confirmations, with times and counts written the way your language writes them. A connector's name and address, its tools' names and descriptions, and a message from its server or from Strata's servers (such as why a check failed) stay as they were written. The catalog's own words are in your language too: what each vendor's connector is for, where its credential comes from and what it may change, in the catalog and the connector's form, and on Customize and the connector's own page in the Directory. The vendor's menu paths and button names (they name the vendor's own screens), addresses, scopes, tool names and a placeholder in angle brackets stay as written.

Whose account a connector uses

Every connector call is made with somebody's credential, and which one is a per-connector choice an admin makes in the connector's own form, with the Each member signs in with their own account switch under Sign-in. It applies to sign-in (OAuth) connectors; a bearer token or a custom header is a single credential the organization holds, so there is nothing to choose.

One shared sign-in is the default and is right for a connector where everyone should see the same thing — a public docs server, a vendor's read-only catalog, an internal wiki. The admin signs in once and every member's question runs on that grant.

Each member signs in with their own account is right wherever identity bounds the data: a CRM's sharing rules, territory management and field-level security; a mailbox; a workspace's private channels. The admin still registers the app with the vendor once — a member never creates an app and never sees a client secret — and each member then authorizes their own account against it. Strata sees exactly what that person can already see, and the vendor's own permission model, sharing rules and audit trail do the rest.

Two consequences worth knowing:

• A per-member connector a member has not signed in to is not offered to the AI at all. It is not offered-and-failing: the AI is never told it exists for that person, so it does not burn a call on a sign-in error. The member sees a Sign in control where the + would be.
• Changing the setting signs the connector out. Flipping to per-member deletes the shared token (one person's account acting for everyone is the thing the switch exists to stop); flipping back to shared deletes every member's grant (a credential nothing reads is a credential nobody revokes). The app registration with the vendor is kept either way, so signing in again costs one round trip, not a new app.

Catalog tiles ship with the setting that suits the tool: most default to one shared sign-in, and Salesforce ships with per-member identity already on, because a CRM's sharing rules are per person.

Turning a connector on for yourself

An admin making a connector available is not the same as your questions starting to go to someone else's server — so each connector is off for you until you opt in.

Open the Directory (the same place you browse skills and extensions) and go to the Connectors tab. Each connector your organization lets you use appears with its logo, a short description of what it does, and a Verified by Strata badge if it came from the catalog. Open one to read exactly what it lets Strata do — including whether it is read-only, and whose account it signs in as — then use the + toggle to turn it on for yourself. Toggle it off again any time.

A connector your organization set to each member signs in shows a Sign in control instead of the +. Pressing it opens the vendor's own consent screen in a popup; approving it both signs you in and turns the connector on for you, in one gesture. Until you do, it is not offered to the AI at all. The connector's About panel states whose account it uses under Signs in as.

Only the connectors you have turned on are offered to the AI. A connector you have not opted in to is never called, even if the whole organization has it enabled.

What the AI does with a connector

Once you have a connector on, its tools join the AI's toolset for your chats. You do not invoke anything by name — ask in plain language, and the AI calls the connector when the question is plainly about what it covers, preferring Strata's own tools for anything they can already answer. To point one message at a connector, type @ in the message box and pick it under Connectors: the AI is told to use it first for that message.

• Tool names are namespaced mcp__<connector>__<tool>, so a connector can never shadow a built-in tool like run_sql.
• Action steps show the connector's own logo, so you can see at a glance when an answer reached out to, say, GitHub or Datadog.
• Everything a connector returns is treated as untrusted third-party content — the same treatment a fetched web page gets. The AI reports what a connector says; it never follows instructions embedded in a connector's response.
• A connector can fail — it is somebody else's server. If one errors, Strata says which connector failed and answers with what it has rather than retrying endlessly.

Note

Connectors work in Strata chat — the web app, the Outlook task pane, and the sub-agents a chat spawns. They are not available to the Teams bot, to scheduled agents, or to the public /v1 API, so a recurring job like a nightly CRM digest cannot be built on a connector today. The first-party extensions reach all of those.

Read-only by default

A new connector is read-only until an admin turns writes on. Be precise about what that enforces, because Strata cannot know what a remote tool actually does:

• When the server labels a tool as destructive, a read-only connector withholds that tool outright.
• When the server does not label its tools (many don't), the tool is still offered, and the AI is told plainly that this connector must not be used to create, change, delete, send or submit anything — even if a tool for it exists and you ask. That is strong guidance, not a hard guarantee.
• The durable control is the credential itself. Where a vendor offers a read-only token or a read-only server address, the catalog tile uses it, and that boundary is enforced by the vendor, not by Strata.

Turning Let this connector make changes on for a connector removes the destructive-tool filter and the read-only instruction. Turn it on only for connectors you intend to let the AI change things in, and prefer a read-scoped credential as the real safety net.

Ask first

When the AI wants to use a tool set to Ask first, the chat shows an approval card naming the tool and the connector, with what the tool will be sent. Nothing reaches the connector's server until the member approves; Deny stops it, and the AI is told the member declined. The card appears every time, in every chat: there is no setting that skips it. A tool you want to run without a card is set to Allow.

Sub-agents are never given an Ask first tool, because nobody can approve a sub-agent's call to it.

Governance and security

A connector is governed as the synthetic extension id mcp:<slug>, so it flows through the same controls as every first-party extension with no new machinery:

• The organization's extension list applies to it while that list is a Ceiling (Organization > Extensions, under How members get an extension).
• A role's extension allow-list can grant or withhold it; a role saved with no extension ticked grants no connector, unless a role bound to one of the member's groups grants it. A per-user deny (the connector's checkbox under Organization > Users > (a user) > Access > Extensions) removes it for one member. See Roles and Users.
• When a per-user deny, a change to the member's role, or a change to the organization's extension list takes a connector away from someone who signed in to it with their own account, that sign-in is deleted, so getting it back means signing in again. Deleting a connector also deletes its per-user denies, so a connector added again under the same id starts with nobody denied.
• Each member's own opt-in is the last gate — the org makes it available, the role allows it, and the member turns it on.

Security properties worth knowing:

• Outbound requests are screened. Every connector request goes through Strata's outbound network guard, which re-resolves the host on every redirect hop and refuses private, loopback and cloud-metadata addresses. A literal internal address is also refused when the connector is saved.
• https only. A bearer token sent to a plain-http endpoint is a credential leak, so it is rejected at save time.
• Credentials are encrypted at rest and are never returned to a browser — the admin panel shows only whether a credential is present, never its value.
• A deployment-wide kill switch (MCP_ENABLED, set by Kronisys on the hosting environment) turns all connectors off at once. It is on unless explicitly disabled; when off, existing rows are still listed for admins but nothing is offered to the AI.
• Connectors are never indexed. What a connector returns is read live to answer one question and is not copied into the Knowledge Base or any other store.

What can go wrong

• A connector you enabled isn't offered to the AI — check that you turned it on for yourself in Directory > Connectors, not just that your org enabled it.
• A connector is enabled for the org but nobody can see it — a role whose connector choices were saved before this connector existed, or a role saved with nothing ticked, is withholding it. The Connectors panel names the roles that withhold it; add it to the ones that need it.
• Test connection fails with an auth error — the credential is wrong, or the server uses its own scheme and needs Custom header rather than a plain bearer. The catalog tile's instructions say which, and for many servers the exact prefix to paste.
• The connector says it can't do something you asked — it may be read-only. A read-only connector refuses to create, change or send anything by design; ask an admin before assuming it's a fault.
• "That server requires a credential Strata does not have yet." — an OAuth connector was added but never signed in, or a bearer tile was enabled before its token was pasted. An admin needs to press Connect or add the token; until then it is not offered to anyone.
• Strata says a connector is not signed in and an administrator needs to reconnect it in Organization › Connectors — the connector's one shared sign-in stopped working. An admin opens the connector under Organization › Connectors and presses Sign in again under Shared sign-in.
• A connector shows a Sign in control instead of the + toggle — it signs each member in individually and you have not signed in yet. Press Sign in; it is not offered to the AI until you do.
• "An administrator has not finished setting this connector up yet." — a per-member connector whose app the admin has not registered with the vendor. Nobody can sign in to it until they do.
• Results look stale or a tool has vanished — the tool list is cached from the last successful connect. An admin can refresh it with Check now in the connector's ⋯ menu, Check all at the top of the Connectors section, or Test connection in its form. Check all skips connectors that are off, and connectors still missing their key or sign-in, and checks the rest one at a time.
• "Not checked · add a key first" or "Not checked · sign in first" — Check all passed the connector by because it cannot authenticate yet, so a check would only fail and use up one of the ten checks a minute. Press add a key or sign in on the row to open the connector at that field. Check now in the row's ⋯ menu still checks it if you ask.
• "Not checked · 10 checks per minute reached" — connection checks are limited to ten a minute per organization. Check all stops at the limit and says on each remaining row how long to wait.
• "Not checked · sign in to test a per-member connector" — a per-member connector can only be checked with your own sign-in. Press sign in on the row to open the connector and press Connect.

Related

• Extensions overview — the whole extension model in one page.
• Roles and permissions — how mcp:<slug> is granted or withheld per role.
• Organization — the Ceiling or Menu setting and org-wide availability.
• Knowledge base — why connector content is never indexed.