如何在 OpenWork Cloud Connectors 中发布共享 MCP 连接并测试工具？-酒店常州论坛

如何在 OpenWork Cloud Connectors 中发布共享 MCP 连接并测试工具？

【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork

如果你的团队里每个人都各自在本机配置 Notion、Linear 或其他 MCP 服务，账号和授权会散落各处。OpenWork Cloud 的Connectors功能让你作为管理员只配置一次——服务器 URL、谁能用、以谁的身份登录——然后成员在自己账号下接入即可。本文面向组织管理员，完成两个连续任务：在 OpenWork Cloud 发布一个共享 MCP 连接，并用 Tool Tester 测试它的工具是否可用；最后说明成员在桌面端连接和验证的方式。适用前提是你在 OpenWork Cloud 已有一个组织，并具备 workspace owner 或 admin 权限。

准备条件

一个 OpenWork Cloud 组织。Cloud 是可选能力：本地桌面应用保持免费、无需 Cloud 登录；需要团队统一管理连接时才使用 Cloud（见 Get started with OpenWork Cloud）。
如果目标 MCP 服务器走 OAuth 且要求注册回调地址，需要提前确认该 provider 接受 OpenWork 的 redirect URL（下文给出具体地址）。
发布连接、测试工具的操作都在 OpenWork Cloud 的 dashboard 里完成，不需要在本地机器上安装任何东西。

发布连接

在 OpenWork Cloud dashboard 打开Connectors。
点击Add connection。
选择预设（Notion、Linear、Stripe、Sentry、Exa、Context7），或直接输入任意 MCP server URL。
选择账号模式：Individual accounts或One org account。
选择可用范围：整个 workspace、指定团队，或指定个人。
点击Create。

账号模式决定 AI 以谁的身份行动，按连接逐个选择：

Individual accounts—— 每个人以自己身份登录，agent 以你的身份行动，provider 侧的权限规则照常生效。这是 OAuth 服务器的默认模式，适合 Notion、Linear 这类每人有自己页面和权限的服务。
One org account—— 管理员登录一次（bot、服务账号或 API key），所有被授权成员的 AI 都以这个身份行动。

选择 One org account 时，发布后还要点击Connect并以组织账号完成 provider 登录才算完成；Individual accounts 连接创建后即可发布，成员各自连接。在Your Connections页面，未连接的 One org account 连接对成员显示Waiting for an admin to connect，workspace owner 和 admin 在该行能看到Connect按钮，可以直接在那里完成组织账号登录。

为 OAuth 服务器注册回调地址

如果 provider 需要预先注册 redirect URL，它属于你这套 Den 部署，不是 MCP server URL 本身。同一 Den 实例上的新 MCP 连接共用这一个地址：

<DEN_API_PUBLIC_URL>/v1/mcp-connections/oauth/callback

托管的 OpenWork Cloud 实例（dashboard 为https://app.openworklabs.com，公开 Den API 为https://api.openworklabs.com）需要在 provider 处注册：

https://api.openworklabs.com/v1/mcp-connections/oauth/callback

自托管实例把api.openworklabs.com换成你的公开 Den API 地址即可，例如公开 API 为https://api.openwork.example.com时注册：

https://api.openwork.example.com/v1/mcp-connections/oauth/callback

provider 会精确比对 redirect URL 的协议、主机、路径前缀和端口，所以必须与DEN_API_PUBLIC_URL的配置完全一致。早期创建的连接使用旧的按连接回调地址的，会自动保留原来注册的 URL，不要为了重新连接而改动它。

如果 provider 拒绝注册 OpenWork（成员会看到 “Providerhasn't approved OpenWork yet”），或它的授权服务器只接受预先注册的客户端，把 Make your MCP server work with OpenWork 页发给对方：其中列出了 redirect URL、client metadata 文档、OpenWork 支持的注册方式，以及一段可直接转发的请求模板。

测试工具：用 Manage → Tool Tester 验证服务器响应

发布后，先由管理员确认服务器确实能用。有两条入口，效果相同：

打开Manage → Connectors，在目标连接行点击⋯ → Test tools；
或直接进入Manage → Tool Tester。Your Connections页面也会给管理员一个扳手快捷入口跳到同一个 tester。

在 Tool Tester 中：选择一个 connector，它会列出该服务器暴露的工具；挑选一个工具，用表单或 JSON 参数运行一次；然后检查请求和响应。这一页上的 tool policy 控件同时决定组织可以启用哪些工具，测试时顺手确认策略符合预期即可。

工具列表能正常返回、单次调用有响应，就说明连接已经可用，可以进入成员连接环节。

成员连接与结果验证

被授权的成员在桌面端完成登录：

登录 OpenWork 后打开Settings>OpenWork Connect。连接按需要采取的动作分组显示：Needs your sign-in（需要成员本人登录）、Needs admin setup（还需管理员配置）、Ready to use。
在Needs your sign-in下找到该服务，点击Connect。
浏览器打开 provider 自己的登录页，批准授权。
浏览器显示Connected，返回 OpenWork。
连接状态自动更新（无需刷新），移入Ready to use。

登录信息存储在 OpenWork Cloud 而非本机，连接一次后所有设备都保持已连接。

验证连接真正打通有两个可核对的点：

文档定义的判定标准：OpenWork 拿到 token 后会向 MCP 服务器执行initialize并列出工具（tools/list），只有工具列表成功返回，成员才会被标记为 connected（见 MCP server compatibility）。
功能层面：连接完成后无需重启或重新同步，直接让 agent 做一件该工具能干的事即可。文档给出的示例请求是：
Find the "Q3 launch" page in Notion and summarize it.
agent 会搜索 OpenWork Connect 中的实时能力并以成员自己的账号执行。如果某个连接需要处理，agent 会指出是哪个账号需要操作，并指向Settings>OpenWork Connect。

可选：将连接直接暴露为 MCP 服务器

默认情况下，agent 通过 OpenWork Connect 的两个发现工具search_capabilities和execute_capability触达所有连接，模型看到的工具列表恒定而简短。对于高频使用的连接，管理员可以在添加或编辑时勾选Expose directly as an MCP server：被授权成员的桌面端会把该连接作为独立 MCP server 注册到 OpenCode，模型直接看到 provider 的真实工具名和 schema，无需搜索步骤。直接暴露的连接在 OpenCode 中以openwork-direct-<name>-…出现。

不变的部分：登录仍在 OpenWork Cloud 完成；访问授权和连接的工具策略（在Manage → Tool Tester中编辑）对每次调用生效；取消勾选、收回成员权限或删除连接后，该服务器会在下一次同步时从所有桌面端移除；成员自行添加的本地 MCP server 不受影响。另外注意：外部 provider 的工具调用要求调用方具备mcp:write权限，即使 provider 声明了readOnlyHint: true也不例外——provider 的提示只描述工具，不授予执行权限。

Slack 的特殊接入路径

Slack 的 MCP 服务器不支持自动 OAuth 客户端注册，需要管理员在 Slack 侧一次性建应用，OpenWork Cloud 之后用它的凭据服务所有成员：

在 Slack API apps（Slack 开发者后台）创建或打开一个 Slack app。
在应用的Agents标签页打开MCP开关——Slack 只为开启该开关的应用提供 MCP 请求。
在OAuth & Permissions中把本 Den 实例的 OAuth redirect URL（见上文）加入 redirect URLs。
按团队需要添加User Token Scopes。只读起步的一组：
```
search:read.public search:read.private search:read.mpim search:read.im search:read.files search:read.users channels:history groups:history mpim:history im:history users:read users:read.email channels:read groups:read mpim:read
```
需要 agent 在 Slack 里执行动作时再追加写权限，例如chat:write reactions:write channels:write groups:write im:write mpim:write canvases:read canvases:write。
为 workspace 安装或批准该应用。
在 OpenWork Cloud 添加 Slack 连接，粘贴应用Basic Information>App Credentials里的Client ID和Client Secret。
成员在Your Connections连接各自的 Slack 账号。

该流程不需要 Slack bot token（xoxb-...或xapp-...）；client secret 不要放进聊天或源码仓库。

排查与限制

成员连不上但 Client ID/Secret 正确（Slack）：确认应用的Agents标签页里MCP开关已打开。
Slack 报 redirect URL 无效：把本实例的 OAuth redirect URL 加进应用的OAuth & Permissions。
Slack 报 scope 无效或不可用：把该 scope 从应用和连接的 scopes 中都删掉再重试——workspace 策略和套餐会限制应用可申请的范围；若 workspace 禁止安装应用，需要 Slack 管理员先批准。
provider 未批准 OpenWork：按上文转发 MCP server compatibility 页面，其中还给出了成员侧各种诊断码（如MCP_OAUTH_REDIRECT_URI_NOT_ALLOWED）与对应修改方式的对照表。
组织策略：Connect 默认开启；平台管理员可用组织的capabilities.mcpConnections设置关闭成员侧连接，客户端版本不能绕过被禁用的组织策略，被禁用的原生动作会返回policy_blocked。重新启用后按成员既有的授权和凭据恢复访问。
授权是服务端强制的：成员只能看到被显式授权（全 workspace、团队或个人）的连接；删除连接或成员权限对所有设备立即生效。发布组织连接不会移除或修改任何人在桌面端的本地配置。

完整的 OAuth 时序（OpenWork 作为公共客户端、PKCE S256、client metadata 文档等）以及 provider 侧需要接受的清单，见 Make your MCP server work with OpenWork；本连接共享的源文档是 Sharing MCP connections with your team。

【免费下载链接】openworkThe open-source alternative to Claude Cowork (powered by opencode)项目地址: https://gitcode.com/GitHub_Trending/ope/openwork

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析