Connectors when you want the organization to manage an MCP integration once
— the server URL, who can use it, and how people sign in — instead of every
member configuring Notion or Linear by hand on every machine.
Two ways to handle whose account the AI uses, chosen per connection:
- Individual accounts — each person signs in as themselves. This is now the default for OAuth servers, and it fits tools like Notion or Linear where people have their own pages, projects, and permissions. The agent acts as you, and the provider’s own access rules apply.
- One org account — an admin signs in once (a bot, service account, or API key). Every granted member’s AI acts as that identity.
Publish the connection in OpenWork Cloud
- Open
Connectorsin the OpenWork Cloud dashboard. - Click
Add connection. - Pick a preset (Notion, Linear, Stripe, Sentry, Exa, Context7) or enter any MCP server URL.
- Choose the account mode:
Individual accountsorOne org account. - Choose who can use it: the whole workspace, specific teams, or specific people.
- Click
Create.
Connect and completing
the provider’s sign-in as the org account. Individual accounts connections are
ready to publish immediately — each person connects themselves.
On Your Connections, an unconnected One org account connection shows
Waiting for an admin to connect to members. Workspace owners and admins get a
Connect button on that row so they can finish the org account sign-in there.
Test tools
Admins open Manage → Connectors, then use the row ⋯ → Test tools, or go directly to Manage → Tool Tester. Select a connector to list its tools, run one with form or JSON arguments, and inspect the request and response. The tool policy controls on this page choose which tools the organization can use. Your Connections also shows admins a wrench shortcut to the same tester.OAuth redirect URL
An OAuth redirect URL, also called a callback URL, is the exact address where the provider sends the browser after a person approves access. It belongs to your specific Den deployment; it is not the MCP server URL or the client metadata URL. New MCP connections on one Den instance share this redirect URL:https://app.openworklabs.com and its public Den API origin is
https://api.app.openworklabs.com. Register this exact redirect URL with the OAuth
provider:
https://api.openwork.example.com, register:
DEN_API_PUBLIC_URL. Providers compare redirect URLs exactly. Existing
connections created with an older per-connection callback keep that registered
URL automatically; do not change it just to reconnect.
Slack
Slack’s MCP server does not support automatic OAuth client registration, so a Slack admin creates a Slack app once and OpenWork Cloud uses its credentials for every member.- Create or open a Slack app in Slack API apps.
- Go to the
Agentstab in the app settings and turn on theMCPtoggle. Slack only serves MCP requests for apps that have this enabled. - In
OAuth & Permissions, add this Den instance’s OAuth redirect URL (see above) to the redirect URLs. - Add the
User Token Scopesfor the Slack MCP tools your team wants agents to use (see below). - Install or approve the app for the workspace.
- In OpenWork Cloud, add the Slack connection and paste the app’s
Client IDandClient SecretfromBasic Information>App Credentials. - Members open
Your Connectionsand connect their own Slack account.
xoxb-... or xapp-...) for this flow. Keep the client secret out of chats and source control.
Slack scopes
Slack MCP uses user token scopes. Choose the smallest set that matches what your team wants agents to do. For a useful read-first setup, start with:Troubleshooting Slack
If members cannot connect even though the client ID and secret are correct, check that MCP is enabled for the Slack app: open it in Slack API apps, go to theAgents tab, and turn on the MCP toggle.
If Slack says the redirect URL is invalid, add this Den instance’s OAuth redirect URL to the Slack app’s OAuth & Permissions redirect URLs. If Slack says a scope is invalid or unavailable, remove it from the Slack app and the connection’s scopes, then retry; Slack workspace policies and plan settings can limit which scopes an app may request. If the workspace blocks app installation, a Slack admin must approve the app first.
What members see in the desktop app
Granted members find the connection inSettings > OpenWork Connect, grouped by what
they need to do:
- Needs your sign-in — individual-account connections that require the member to authenticate or reconnect.
- Needs admin setup — connections that an organization admin still needs to configure or authenticate.
- Ready to use — connections ready for the agent, including accounts managed by the organization.
Connect your account
- Sign in to OpenWork, then open
Settings>OpenWork Connect. - Find the service under
Needs your sign-in, then clickConnect. - Your browser opens the provider’s own sign-in page. Approve access.
- The browser shows
Connected— return to OpenWork. - The connection updates by itself, no reload needed, and moves to
Ready to use.
Your agent can use it immediately
No restart, no resync. Ask for something the tool can do:Find the “Q3 launch” page in Notion and summarize it.The agent searches the live capabilities available through OpenWork Connect, then executes an exact match with your account — your permissions, your audit trail on the provider’s side.
Settings > OpenWork Connect.
Expose a connection directly as an MCP server
By default the agent reaches every connection through OpenWork Connect’s two discovery tools,search_capabilities and execute_capability, so the model
sees a small, constant tool list no matter how many connections you publish.
For a connection the agent uses constantly, an admin can instead tick
Expose directly as an MCP server when adding or editing it. Granted members’
desktop apps then register that connection as its own MCP server in OpenCode,
so the model sees the provider’s real tool names and schemas up front and calls
them without a search step. The same option is available from any MCP client
that reads the OpenWork Connect server index.
What stays the same:
- Sign-in still happens in OpenWork Cloud. The desktop app never receives the provider’s URL or token; it talks to Den’s per-connection endpoint with the member’s own OpenWork credential.
- Access grants and the connection’s tool policy, edited in Manage → Tool Tester, are enforced on every call.
- Turning the option off, revoking a member’s access, or removing the connection removes the server from every desktop on the next sync.
- Member-added local MCP servers are never touched.
openwork-direct-<name>-….
Notes for admins
- Members only see connections they’ve been granted — access is explicit (workspace-wide, team, or per-person), and it’s enforced by the server on every request, not by the app.
- Removing a connection (or a member’s access) takes effect immediately for every device.
- Members who already connected a tool directly in their desktop app keep their existing setup — publishing an org connection never removes or changes anyone’s local configuration.