接 MCP 之前，WorkBuddy 给我的感觉是「很会出主意」。
接之后，它第一次让我有点不习惯：我说「把这三个竞品页面的价格、套餐、更新日期抄下来，做成表」，它没给我步骤，而是真的去开了浏览器，一页页点，把结果贴了回来。
这就是 MCP 带来的变化。不是多了一个按钮，是它多了一双手。
这篇讲清楚三件事：MCP 是什么、接上之后多出哪些能力、以及怎么接才不出事。
一、MCP 不是插件，是一条标准接口
你可以把它想成一个「翻译协议」。
WorkBuddy 这边是客户端，负责决定「要做什么」；MCP Server 那边是服务端，负责把外部系统的能力翻译成一个个「工具」；真正干活的，是后面的浏览器、文件、数据库、业务 API。
它的好处是通用。今天接一个浏览器 Server，它就会开网页；明天换一个数据库 Server，它就会查库。WorkBuddy 本身不用改，换的是「手脚」。
这也是它和普通插件的区别：插件是给某个软件定制的，MCP 是一套大家都能说的语言。
二、接上之后，多出来三类能力
第一类，浏览器。
这是最能直观感受到的一类。开页面、点按钮、填表单、截图、抓数据，它都能做。
我常让它干的活是：打开几个竞品页面，把价格和更新日志抄下来，整理成对比表。以前这活得我自己点半小时，现在一句话，它跑完给我。
第二类，文件和数据库。
给它一个目录，它能读、能写、能批量改名、能按内容归档。给它一个只读数据库账号，它能跑查询、把结果整理成表。
这一类要特别小心权限。目录给一个就够，别给全盘；数据库先给只读，别给写。
第三类，业务系统。
GitHub 能读 issue、查 PR、看提交；办公协作能读群消息、发通知、建日程；再往外，地图、搜索、监控，只要有对应的 MCP Server，都能接成它的工具。
一句话判断值不值得接：你每天要重复「打开某个系统、点几下、把结果搬回来」的事，就值得。
三、怎么接
配置不难，难的是别接错地方。
第一步，打开用户目录下的 mcp.json。注意，是 mcp.json，不是带点前缀的 .mcp.json，这两个不是一个文件。
第二步，在 mcpServers 里加一个条目。本地服务写 command 和 args，远程服务写 url 和 headers。比如接 Playwright，command 写 npx，args 写它对应的包名。
第三步，进连接器管理页，找到新加的服务，点「信任」。
这一步最容易被忽略。配置写对只是「登记」，不点信任，它不会自己生效。
第四步，回会话里验一下。让它做一件只有这个 MCP 才能做的事，比如「打开这个页面，把标题和第一段抓下来」。能做成，才算通。
四、四条安全底线
MCP Server 不是网页书签，它是能在你机器上跑命令的程序。所以有四条底线。
第一，只装可信来源。来路不明的 Server，别装。
第二，最小权限。只给一个目录、一个只读库、一个测试环境，别一上来给全盘和 root。
第三，密钥进环境变量。别把 token 写进聊天记录，也别提交到仓库。
第四，先只读，再写。先让它查、看、总结；确认行为可控，再开写入和执行。
记住一句话：它接上以后，能做的事和你账号的权限一样大。你给它的每一个权限，都要能随时收回。
五、我的建议
别一次接五个。
先挑一个最痛的场景，接一个只读的 Server，跑一周。看它调用得准不准、会不会乱开页面、会不会把不该读的文件读了。
跑顺了，再加第二个；需要写入时，再单独开权限。
MCP 的价值不在「接得多」，在「接得对」。接一个每天都能用上的，比接十个吃灰的强。
结尾
接 MCP，本质上是给 WorkBuddy 装一双手。
手越多，能做的事越多；但手越多，越要管好它伸向哪里。
想试的话，今天只做一件事：挑一个你每天都要重复的网页操作，接一个浏览器 MCP，让它替你跑一次。
跑通那一次，你就知道它还缺哪双手了。
热门跟贴