用户拿到一个 MCP 链接，第一反应往往不是打开 LLM 客户端，而是粘进浏览器。
然后他看到 401 Unauthorized，再加一段原始 JSON。判断也很自然：服务坏了。
但服务没坏。401 在这里是正确的认证语义。错位的是入口：这个 URL 本来给客户端用，却长得像一个普通网页链接。
HybridLogic 给自家主要工具上线 MCP Server 后，遇到的就是这个问题。客户直接打开 /mcp，看到错误页，提交支持工单。团队最后做了一个很小的改动：当请求是 GET /mcp，并且 Accept 包含 text/html，同时不包含 application/json 或 text/event-stream，就返回一页 HTML 说明，而不是把机器看的错误直接甩给人。
结果很实在：支持工单大幅减少，客服负担变轻，客户配置也更快。
小 HTML 页，补上了 MCP 的第一眼
这事可以先压成一张对照表：
| 场景 | 原来 | 改完之后 |
|---|---|---|
| 用户动作 | 浏览器打开 /mcp | 浏览器仍可打开 /mcp |
| 页面反馈 | 401 Unauthorized 和原始 JSON | HTML 引导说明页 |
| 技术语义 | 未认证，请求被拒 | 不影响真正客户端接入 |
| 用户判断 | 以为服务坏了 | 知道要去客户端配置 |
| 团队后果 | 支持工单增加 | 工单减少，配置更顺 |
MCP Server 的目标，是让 AI 客户端调用外部工具和服务。开发者理解这套逻辑：URL、认证、客户端配置、工具调用。
普通用户不会这么拆。他只看到一个链接。链接就该能点开。
所以问题不在用户笨，也不在 401 本身。问题在于，一个面向机器的端点被交给了真实用户，却没有给真实用户准备第一眼解释。
这类误解会直接打到两类人身上。
一类是正在接入 MCP 的开发者。他们以为“客户端能连通”就算上线，结果上线后要反复解释同一句话：不是服务坏了，你要把地址贴到客户端。
另一类是 AI 产品经理和开发者工具团队。他们原本想靠 MCP 降低接入成本，却在 onboarding 上把成本补了回去。客户配置不顺，采购和试用就会变慢。企业客户尤其如此，内部一旦把“配置麻烦”贴成标签，推进节奏会立刻降速。
HybridLogic 的办法朴素，但抓住了点：不改协议主流程，只在浏览器误访问时接住用户。
这比写十页文档更有用。因为用户不是先读规范，再走流程。用户先点开链接。
真问题不是 401，而是规范没替人收口
我不太买账的是很多 AI 工具链默认的那套思路：只要协议定义清楚，剩下就是用户和客服的事。
这在开发者社区里能跑。在真实客户现场会漏水。
HybridLogic 也提到过另一个路线：为每个 LLM 客户端打包 connector 或 plugin。听起来更正规，实际约束很硬。
| 路线 | 好处 | 现实约束 |
|---|---|---|
| 给每个客户端做 connector/plugin | 用户体验可能更完整 | 客户端碎片化，维护慢，像打地鼠 |
| 只暴露 MCP URL | 接入轻，协议通用 | 用户容易把 URL 当网页打开 |
| 给浏览器访问返回说明页 | 改动小，能快速止血 | 仍不能替代完整客户端体验 |
这里不能夸大。一个 HTML Hello Page 不是 MCP 的完整产品化方案，也解决不了所有客户端兼容问题。
它只是补了最容易出血的一刀：用户第一次看到它时，不要被机器错误页劝退。
这件事也说明，MCP 不是不可用。正因为有人用，才会暴露这种边角问题。原作者对 MCP specification 的评价很尖，认为它作为规范做得糟糕。这个判断可以争。但至少在浏览器误访问这件事上，规范缺少足够顺手的缓解机制。
成本于是外溢。
协议层没收住，产品层要收。产品层没收，客服收。客服收不住，客户就把“接不上”记在产品头上。
“天下熙熙，皆为利来。”AI 工具入口现在也是这样。工具厂商想快点接进模型，客户端想快点扩生态，企业想快点把内部系统挂上去。大家都在抢速度，最容易被牺牲的就是第一眼体验。
这不是新故事。
早期互联网、RSS、OAuth、移动 App 深链，都经历过类似阶段：协议先通，体验后补。情况不完全一样，但惯性相同。工程系统觉得“能连上”就算完成，产品系统知道“人知道怎么连”才算开始。
MCP 这类 AI 时代的工具协议，真正的考验不只是能不能调用工具，而是能不能把真实用户从错误入口带回正确路径。
做 MCP Server，至少把这几件事做掉
如果你正在做 MCP Server，别只测 Claude、桌面客户端或内部 Agent 能不能连。
也用浏览器打开一次你的 MCP 地址。
如果你看到的是一坨认证错误，协议可能没错，但 onboarding 已经漏了。更稳的做法，是给明显来自浏览器的请求返回说明页。
这页不用复杂，但该有几件事：
- 说明这是什么.这是 MCP Server，不是普通网页应用。
- 说明该怎么用.把这个地址添加到支持 MCP 的客户端。
- 说明支持哪些客户端.只写你确认过的，不要硬列。
- 说明认证方式.提示需要登录、Token 或由客户端完成授权，但不要泄露敏感信息。
- 说明常见错误.比如未授权、客户端不支持、配置位置不对。
- 给一个支持入口.让用户带着上下文求助，而不是只截一张 401 图。
这里有两个限制要守住。
第一，不要为了“好看”破坏认证语义。真正的 JSON 请求、SSE 请求、客户端请求，该怎么处理还怎么处理。HybridLogic 的条件就很克制：GET /mcp，Accept 里有 text/html，并且没有 application/json 或 text/event-stream。
第二，不要把 HTML 页写成营销页。用户来这里不是看品牌故事。他只想知道：这是什么、为什么打不开、下一步点哪里。
接下来真正该观察的，不是有多少团队复制这个小 hack，而是 MCP 相关工具会不会把“人类可读入口”当成默认设计。
如果每个服务端都自己补一页，短期有效，长期会变成新的碎片化。有人写得清楚，有人继续甩错误，有人把说明页做成广告页。标准没有收口，体验就会继续漂。
所以这个案例最有价值的地方，不是证明 HybridLogic 多聪明，而是提醒接入 MCP 的团队：别把面向机器的端点，裸露给面向人的流程。
协议能跑，只是起点。用户不误判，客服不反复解释，客户能独立完成配置，才算产品真正交付。
一个 401 页面看似小事，分水岭就在这里：你是在发布一个协议端点，还是在交付一个能被人走通的工具入口。