工具与 MCP

在 Workova 里，工具 页面当前主要承接的是 MCP 服务管理。

你可以把它理解成：

给 Agent 接外部工具能力
给工作流补外部执行能力
让本地和远程服务进入统一工具目录

页面入口

当前 GUI 入口：

左侧导航：工具
路由：/mcp

当前页面能做什么

基于当前页面实现，MCP 管理支持这些动作：

查看服务列表
搜索服务
添加 MCP 服务
测试连接
刷新工具
连接 / 断开
删除服务

添加 MCP 服务的两种方式

JSON 导入

适合：

你已经有现成的 MCP 配置
团队里有人直接给了你 JSON
你想一次性导入多个服务

手动填写

适合：

你正在第一次配置服务
你需要精细控制每个字段
你想逐项检查命令、参数、环境变量

手动填写时最重要的字段

服务名称

这个名字会直接出现在服务列表和工具来源里，建议写成你自己一眼能认出来的名字。

传输方式

当前页面会让你选：

本地
远程

你可以简单理解成：

本地：通过命令启动
远程：通过 URL 连接

本地模式要填什么

启动命令
命令参数
环境变量

适合：

你机器上已经有本地 MCP 服务
你希望直接从桌面端拉起它

远程模式要填什么

服务地址
请求头

适合：

MCP 服务已经部署在远程环境
团队统一提供了服务地址

服务加进来之后，还要做什么

一般建议按这个顺序来：

先 测试
再 刷新工具
确认工具数正常
再 连接

这样可以先排掉连接参数错误，而不是直接把问题留到运行时。

页面里每个动作分别是什么意思

测试

检查这条服务配置能不能正常访问。

刷新工具

重新读取当前 MCP 服务暴露的工具列表。

连接

让当前服务进入可用状态，后面 Agent 或流程才能真正调用它。

断开

停止使用当前服务，但保留配置。

删除

把这条服务配置从列表中移除。

什么时候你应该先做 MCP，而不是先做插件

适合先做 MCP 的情况：

外部能力本来就是一个 MCP 服务
你更关心“接进来能调用”而不是“做成平台原生扩展”
团队已经有现成的远程工具服务

适合看插件开发的情况：

你要定义自己的 manifest
你要做命令型、渠道型或 skill bridge 型扩展
你要在 Workova 里长期维护一个原生扩展

下一步读什么

想从终端管理 MCP：CLI 命令分组
想继续理解上下文接入：连接 MCP 与上下文能力
想自己做扩展：插件开发入口