Skip to main content
Use 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

  1. Open Connectors in the OpenWork Cloud dashboard.
  2. Click Add connection.
  3. Pick a preset (Notion, Linear, Stripe, Sentry, Exa, Context7) or enter any MCP server URL.
  4. Choose the account mode: Individual accounts or One org account.
  5. Choose who can use it: the whole workspace, specific teams, or specific people.
  6. Click Create.
For a One org account connection, finish by clicking 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:
For the hosted OpenWork Cloud instance, the dashboard is 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:
For a self-hosted instance whose public Den API is https://api.openwork.example.com, register:
Use the exact scheme, hostname, optional path prefix, and port configured in 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.
  1. Create or open a Slack app in Slack API apps.
  2. Go to the Agents tab in the app settings and turn on the MCP toggle. Slack only serves MCP requests for apps that have this enabled.
  3. In OAuth & Permissions, add this Den instance’s OAuth redirect URL (see above) to the redirect URLs.
  4. Add the User Token Scopes for the Slack MCP tools your team wants agents to use (see below).
  5. Install or approve the app for the workspace.
  6. In OpenWork Cloud, add the Slack connection and paste the app’s Client ID and Client Secret from Basic Information > App Credentials.
  7. Members open Your Connections and connect their own Slack account.
You do not need Slack bot tokens (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:
Add write scopes only if you want agents to take action in Slack:
Use this table to pick scopes by capability:

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 the Agents 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 in Settings > 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

  1. Sign in to OpenWork, then open Settings > OpenWork Connect.
  2. Find the service under Needs your sign-in, then click Connect.
  3. Your browser opens the provider’s own sign-in page. Approve access.
  4. The browser shows Connected — return to OpenWork.
  5. The connection updates by itself, no reload needed, and moves to Ready to use.
Your sign-in is stored in OpenWork Cloud, not on this machine — connect once and every device you use is connected.

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.
If a connection needs attention, the agent should tell you which account needs action and direct you to 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.
Directly exposed connections appear in OpenCode as 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.

Relationship to local MCP servers

Add a custom MCP server still works without a cloud account. Use that advanced path for local tools or servers your organization does not provide. Use Connect for accounts and services managed through OpenWork Cloud.