一、GitHub：看的不是代码，是「还在不在维护」

打开一个仓库，第一眼看三样：最后一次提交是什么时候、release 有没有打 tag、issue 区有没有人回。 这三样加起来大约十秒，比读 README 有用。README 可以写于两年前，提交时间骗不了人。 第二眼看目录结构：有没有 tests、有没有 CHANGELOG。有这两样的项目，作者通常是认真在维护的。

第三眼才看代码。而且不用全看，只看工具是怎么注册的——那里决定它有哪些能力、参数怎么校验。 看源码的目标不是读懂它，是回答一个问题：这个工具在什么条件下会返回空。 这句话第 5 章这一节讲完，第 8 章会用上。

二、issue 区：别人的坑，你的捷径

issue 区是性价比最高的地方。搜之前先想清楚搜什么词——用报错原文搜，不要用你的理解搜。 搜到了先看有没有人回、有没有被关。关掉的通常是解决了，开着没回的说明维护者不在。 一个实用技巧：按「最近更新」排，不要按「最多回复」排。最多回复的那个往往是吵架帖。

演示里那条 issue 答复是本书里最好的一条范例：「把 server 的 stderr 打出来，一般是有依赖没装」。 它好的地方在于给了下一步动作，而不是给了一个结论。 结论可能错，动作不会——你去打了 stderr 就知道是不是依赖没装。

三、魔搭社区与 Discord：问人之前先自问

魔搭社区的讨论区偏中文，问中文问题回得快。Discord 是官方的实时频道，人多、回得快，但英文。 两个地方共同的规矩：先搜再问。 直接甩一句「不好使」，多半没人理； 带上原文、配置、期望，回得很快。 演示里那段对比很值得看。差的那句是「我的 Server 不好使，工具出不来」； 好的那句把三样都给了：我做了什么、看到什么、期望什么。

好的那句长这样：initialize 回 tools 空对象，tools/list 回空数组，server 是自己写的， 工具在列表里有三条。 它甚至不需要提问——把这三行贴出去，懂的人一眼就说出问题在哪。 这就是「带上原文比带上理解更有用」的意思。

四、三个渠道，顺序不能反

源码：能确切知道它在什么条件下返回空，十分钟到一小时，可信度高。 issue 区：能不能知道别人踩过没有、有没有人回，几分钟，可信度中。 聊天群：多半是「我也遇到过」「重装试试」，几分钟，可信度低。

先问人的代价不只是拿到过时答案，还占了别人的时间。而且一旦习惯了问人，就不再去读源码了。 顺序反过来也有个例外：如果你连「该搜什么词」都不知道， 那先问一句「这个报错大概是什么方向」是合理的。拿到方向之后，还是回去搜。

五、提 issue 的四个格子

照着填，基本一次就能问清：环境、最小配置、看到的原文、期望。

四格里最常漏的是第三格。贴一句「报错了」，等于什么都没说。 第二格也常漏，但它决定别人能不能复现。把配置里的路径换成占位符就行，结构一个字别改。 这一节没有代码，但它是全书最省时间的一节。省的是别人的时间，也是你的。

六、动手 Demo：三个渠道，三种答案

同一个问题，在源码、issue 区、聊天群三个地方拿到的答案完全不同。 逐条看它们能不能照着做，最后给一张提问模板。 这一节全是文本比对，不跑代码；三段答复都是照着常见的真实回复编的。

ANS = [('聊天群', '我这边也报过，重装一遍就好了'),
       ('issue', '把 server 的 stderr 打出来，一般是有依赖没装'),
       ('源码', 'tools 在 register 之后才填充，没调 register 就是空')]

ACT = ('打', '查', '改', '加', '删', '打印', '重新', '运行', '跑')

for src, text in ANS:
    ok = any(w in text for w in ACT)
    print('%-6s %-4s %s' % (src, '能动手' if ok else '不能', text))

# 一份能问出答案的模板
TPL = '''环境：Windows 10 / python 3.13 / 宿主某版本
配置：{json 原文，路径打码}
看到：initialize 回 {tools:{}}，tools/list 回 {"tools":[]}
期望：应该列出我在 TOOLS 里写的 3 个工具'''

实跑输出：

--------------------------------------------------------------------
三个渠道，三种答案
--------------------------------------------------------------------


  ① 同一个问题，三种回答
  --------------------------------------------------------------------
这个问题的答案，在三个地方拿到的是三样东西：

| 渠道 | 能拿到什么 | 多久 | 可信度 |
|---|---|---|---|
| 源码 | 确切知道它在什么条件下返回空 | 十分钟到一小时 | 高 |
| issue 区 | 别人踩过没有、有没有人回 | 几分钟 | 中 |
| 聊天群 | 「我也遇到过」「重装试试」 | 几分钟 | 低 |

  三样都有用，但顺序不能反。先搜 issue，再翻源码，最后才问人。
  【先问人，往往拿到一个已经过时的答案】，还把别人的时间占了。

  ② 三种答复，哪种能直接动手
  --------------------------------------------------------------------


| 来源 | 答复 | 能照着做吗 |
|---|---|---|
| 聊天群 | 我这边也报过，重装一遍就好了 | 不能：不知道是哪个问题好了 |
| issue | 把 server 的 stderr 打出来，一般是有依赖没装 | 能：给了下一步动作 |
| 源码 | tools 在 register 之后才填充，没调 register 就是空 | 能：定位到具体那行 |

  判据很简单：【这句话能不能变成一个可以执行、可以验证的动作】。
  「重装试试」不能（成功了你也不知道为什么），「打印 stderr」能。

  ③ 一个能把人问住的细节
  --------------------------------------------------------------------
注意第三条：它说的是「没调 register」，不是「没写工具」。
这两句话离得很近，指向的地方完全不同：一个在注册流程，一个在工具定义。
  所以问问题的时候，【带上你看到的原文】比带上你的理解更有用。

两种提问方式，收到回复的概率差很多：
  差：我的 Server 不好使，工具出不来
  好：initialize 回 {tools:{}}，tools/list 回 {"tools":[]}，
      server 是我自己写的，工具在 TOOLS 列表里有 3 条
  后者把「我做了什么、看到什么、期望什么」三样都给了。

  ④ 提 issue 的四个格子
  --------------------------------------------------------------------
照着填，基本一次就能问清：

| 格子 | 填什么 | 少了会怎样 |
|---|---|---|
| 环境 | 系统、python 版本、宿主名字和版本 | 别人复现不出来 |
| 最小配置 | 那份 json 原文，路径可打码 | 看不出是配置错还是代码错 |
| 看到的原文 | 报错、返回的 JSON，原样贴 | 只能靠猜 |
| 期望 | 你以为会发生什么 | 不知道这算不算 bug |

  四格里最常漏的是第三格。【贴一句「报错了」，等于什么都没说。】
  ! 这一节没有代码。但它是全书最省时间的一节——省的是别人的时间，也是你的。

①第一张表三行，可信度从高到低。注意「源码」那一行的时间成本最高，但它给的答案最确定。 ②第二段三句答复，只有后两句能动手。第一句「重装一遍」成功了也不知道为什么，这就是它没用的原因。 ③第三段那一句「没调 register」而不是「没写工具」，两个说法差一个词，指向的地方完全不同： 一个在注册流程，一个在工具定义。 ④最后那份模板把「我做了什么、看到什么、期望什么」三样都给了。 把这三行贴出去，往往不用提问，懂的人直接就说问题在哪。 ⑤这一节没有代码要跑，但它值得反复看。提问方式决定你能不能拿到答案。

30 秒实验

1. 找一个你以前提过的问题，按四个格子重写一遍。看是不是能写得更短更准。
2. 去任意一个仓库的 issue 区，用报错原文搜一次，再用你的理解搜一次。看哪次搜到的东西更相关。
3. 给自己定一条规矩：以后遇到问题，先搜十五分钟再问人。写下这条规矩。

常见误区

1. 「有问题直接问群最快。」拿到过时答案的概率很高，而且习惯了就不读源码了。
2. 「issue 区都是别人踩的坑，跟我无关。」同一个工具同一个版本，坑是一样的。搜到就是省下半小时。
3. 「贴一句报错了，别人就知道。」别人看不到你的屏幕。原文、配置、期望，三样缺一样都要来回问。

找 Server 这一章到此结束。下一篇换一件事：不再找别人的，自己写一个。 第 6 章从装环境开始，到一个能跑的 Server 加一个能连的 Client。

• ☐ （本篇完，下一篇 6.1 搭建 MCP 开发环境）

相关笔记

• MCP Server 国外整合平台
• 19 网络与信息安全 · 索引
• 21 Web 技术原理 · 索引
• 🔌 MCP 极简开发 · 索引