波仔
🔌 第8章 基于MCPServer的IDE应用实战
📄 一句话概括

两个案例：用 GitHub MCP 查仓库，用 Figma MCP 读设计稿。 一个跑在本机（stdio），一个跑在厂商云上（http），配置界面却是同一套。 这一节真正要看的不是两个工具，是「只读工具和写工具在一张表里怎么分级」。

📝 本章和前面几章的关系

第 7 章讲完了开发。从这一章开始全是案例，一共二十个。 这一章的两个案例都在 IDE 里做，用的是别人写好的 Server。 所以这一节不用写代码，但要看清一件事：工具是谁写的，决定你能放心到什么程度。

一、两个案例，两种连法

GitHub MCP 跑在本机，stdio，起一个子进程，靠一个个人访问令牌访问你的仓库。 Figma MCP 跑在厂商云上，http，只要一个地址加团队令牌。 一个在本机、一个在云上，可宿主的配置界面长得一样：要么填 command 加 args，要么填一个地址。

这正是第 4 章那句话的实例：协议统一的好处，是两种形态的 Server 在宿主看来没有区别。 但差别在别处——本机那个能读你磁盘上的文件，云上那个读不到。这一点决定了两者的风险不同。

二、GitHub 侧：三个工具，两读一写

演示里给了三个工具：search_repos 搜仓库、get_file 读文件、create_issue 提 issue。 前两个是只读。搜错了再搜一次，读一百遍结果一样，所以不需要确认。 create_issue 是写：发出去别人就看见了，撤不回来。所以它需要人点一下。

这就是第 3 章那道闸落到具体工具上的样子： 同一个 Server 里也有分级，不是按 Server 分，是按工具分。 教材里这一步是在 Cline 的对话框里让它「看看 notes 相关的仓库」，然后再让它读某个文件。 两步都是只读，都没弹窗。

三、写操作那一步值得单独看

演示里提的那个 issue，标题是「mcp.py 里少一条 note.del」，正文是「工具表里没有删除， 用户问删一条时无工具可用」。 这两句话都不是用户说的，是模型读完代码之后自己总结的。 能自己写内容的写操作，风险比「照抄用户的话」高一个量级：它会写错、会写偏、 会在你没看清的时候发出去。

所以确认框要能看清全文，不能只显示「即将创建一个 issue」。 确认的价值在于「你能审」，不在于「你点了」。 顺带一个实用建议：给这类工具加一个 draft 参数，先建草稿、再发布。多一步，但可撤。

四、Figma 侧：拿到的是结构，不是图片

演示里取一帧 375 乘 812 的页面，回来三个子节点：一个文本「我的笔记」、一个实例「6 个卡片」、 一个文本「新建」。 它给的是结构，不是像素。 模型拿不到设计稿长什么样，只拿到名字、层级、尺寸、文案。 这就是「照着设计稿写页面」能还原到八九成的原因——布局和文案能对上，间距、圆角、阴影这些得人补。

想让模型多拿一点，就得让工具多返回一点：颜色、字号、间距，都能加进返回结构。 工具的返回结构决定了模型能还原到什么程度。 这是这一节最实用的一句。

五、两个 Server 一起用，要注意什么

演示最后把四个工具合并在一张表上：三个 GitHub 的、一个 Figma 的，名字都带前缀。 一句话里出现两个动作——「看看 notes-api 那个仓库，顺手读一下 mcp.py」——模型会拆成两次调用。 拆这一步协议不管，宿主也不管，是模型自己做的。

所以 Server 侧能做的只有一件事：把描述写得让人一眼看懂在什么场景用。描述含糊，模型就拆错。 装两个 Server 的代价是工具表变长。 四个工具还好，装到六个 Server 就是几十条，第 11 章最后会算这笔账。

六、动手 Demo：在 Cline 里查仓库、读设计稿

造两个 Server：一个 GitHub 的三个工具，一个 Figma 的一个工具。 依次跑一遍搜索、读文件、提 issue、取设计稿节点，看只读和写在确认上的差别。 工具都是真注册、真调用的，数据是照真实字段造的。

gh = Server('github-mcp')      # 本机起进程，stdio
gh.add(Tool('github.search_repos', '按关键词搜仓库', SCHEMA, fn))
gh.add(Tool('github.get_file', '读仓库里某个文件', SCHEMA, fn))
gh.add(Tool('github.create_issue', '新建一个 issue（写操作）', SCHEMA, fn))

fg = Server('figma-mcp')       # 厂商托管，http
fg.add(Tool('figma.get_node', '按节点 id 取一帧的结构', SCHEMA, fn))

# 只读：直接调
print(call(gh, 'github.search_repos', {'q': 'notes'}))
print(call(gh, 'github.get_file', {'path': 'acme/notes-api/src/mcp.py'}))

# 写：宿主会先弹确认，确认之后才发
print(call(gh, 'github.create_issue', {'repo': 'acme/notes-api',
                                        'title': 'mcp.py 里少一条 note.del'}))

实跑输出：

--------------------------------------------------------------------
在 Cline 里查仓库、读设计稿
--------------------------------------------------------------------


  ① 两个 Server，两种连法
  --------------------------------------------------------------------

|  | GitHub MCP | Figma MCP |
|---|---|---|
| 跑在哪 | 本机起进程（stdio） | 厂商托管（http） |
| 要什么 | 一个个人访问令牌 | 一个团队令牌 |
| 能碰什么 | 仓库、issue、PR、文件 | 设计稿的节点与文案 |
| 典型动作 | 搜代码、读文件、提 issue | 取一帧的尺寸和文字 |

  一个在本机、一个在云上，配法却是同一套：command 加 args 或者一个地址加令牌。
  【这就是协议统一的好处：两种形态的 Server，宿主的配置界面长得一样。】

  ② GitHub 侧：三个工具，先搜再读
  --------------------------------------------------------------------
用户说：帮我看看 notes 相关的仓库。

| 仓库 | 说明 | 语言 | 星数 |
|---|---|---:|---:|
| acme/notes-web | 前端笔记站 | TypeScript | 128 |
| acme/notes-api | 笔记服务的后端 | Python | 96 |


再把后端那个仓库的 MCP 入口文件读出来：
  {"path": "acme/notes-api/src/mcp.py", "text": "TOOLS = ['note.add', 'note.list', 'note.search']…
  搜和读都是只读动作，宿主不会拦。下发这三步之后，模型才知道该改哪个文件。

  ③ 写操作要确认：同一个 Server 里也有分级
  --------------------------------------------------------------------

| 工具 | 读还是写 | 要不要确认 | 为什么 |
|---|---|---|---|
| github.search_repos | 读 | 不用 | 搜错了再搜一次 |
| github.get_file | 读 | 不用 | 读一百遍也一样 |
| github.create_issue | 写 | 要 | 发出去别人就看见了 |

真提一个 issue，参数是模型从上下文里拼的：
  {"number": 101, "title": "mcp.py 里少一条 note.del", "state": "open"}
  注意 body 里那句话——它不是用户说的，是【模型读完代码之后自己总结的】。
  能自己写内容的写操作，确认这一步不能省。

  ④ Figma 侧：取一帧的尺寸和文案
  --------------------------------------------------------------------
用户说：照设计稿把这个页面写出来。
  帧：笔记列表页  375 x 812
    TEXT 标题       我的笔记
    INSTANCE 卡片       6 个
    TEXT 底部按钮     新建
  这一步给的是【结构，不是图片】。模型拿不到像素，只能拿到名字、层级、尺寸、文案。
  所以「照着设计稿写页面」这件事，能还原到八九成，剩下的一两成得人补。

  ⑤ 四个工具合在一起，一句话挑两次
  --------------------------------------------------------------------

| 工具 | 发起人 | 副作用 |
|---|---|---|
| github.search_repos | 模型 | 无 |
| github.get_file | 模型 | 无 |
| github.create_issue | 模型 | 有 |
| figma.get_node | 模型 | 无 |

用户这句话里其实有两个动作，模型要挑两次：
  第 1 次挑：github.search_repos   参数 q=notes
  第 2 次挑：github.get_file       参数 path=acme/notes-api/src/mcp.py
  【一句话里两个动作，协议不管，宿主也不管，是模型自己拆的。】
  四件事里只有 create_issue 会改变外部世界，所以只有它需要人点一下。

①第一张表最后一行是重点：一个在本机跑、一个在云上跑，可配置界面是同一套。这就是协议统一的意义。 ②第二段那张三行的表按读／写分级。注意分级不是按 Server，是按工具——同一个 Server 里也有要确认的。 ③第三段提 issue 的参数里，正文是模型自己总结的。这才是写操作最该小心的地方：它会自己编内容。 ④第四段取回的是一帧的结构：尺寸 375 乘 812，三个子节点分别是文本、实例、文本。 没有像素，只有名字和文案。 ⑤最后那句提醒很重要：工具的返回结构，直接决定模型能还原到什么程度。 想让它还原得多，就多返回几个字段。

30 秒实验

  1. 把 create_issue 的确认关掉，再跑一次。想想最坏会发生什么。
  2. 给 figma.get_node 加两个字段（字号、圆角），看模型能不能还原得更准。
  3. 数一数你装的 IDE 插件里，有几个带写操作的工具。

常见误区

  1. 「只读工具不用管。」只读也会泄露：一个能读任意路径的工具，能把密钥读出来。 第 3 章那三个攻击里有两个靠读。
  2. 「同一个 Server 的工具，风险一样。」风险按工具算，不按 Server 算。 一个 Server 里可以既有查询也有删除。
  3. 「设计稿能一键还原成页面。」拿到的只有结构和文案，间距、颜色、动效都得补。
自测三问（点开对答案） 1. GitHub MCP 和 Figma MCP 的连法差在哪？ —— 一个本机 stdio 起进程，一个厂商托管走 http。配置界面一样，差别在能不能碰本机文件。 2. 为什么确认框要显示全文？ —— 因为 issue 的正文是模型自己写的。看不清全文，「确认」就变成闭眼点。 3. Figma 工具返回的是什么？ —— 结构：节点名、类型、尺寸、文案。不是图片，也没有像素。

Cline 上两个案例讲完，下一节换到 Trae，一次看六个——它们其实是同一个模板。

相关笔记