文章核心内容：作者团队为$WORK工具提供了MCP服务器，但用户常误将API链接在浏览器打开导致401错误。为解决这个问题，作者没有选择为每个LLM客户端开发插件，而是通过检测请求头返回HTML页面来引导用户正确使用API。

文章标题：MCP服务页面优化实践

核心内容：

我们为$WORK工具推出了MCP服务器服务，虽然MCP作为"规范"存在缺陷，但实际运营中遇到一个棘手问题：用户频繁报告MCP服务器无法使用。

问题根源： 当用户在浏览器直接访问mcp.acme.com/mcp时，会收到401错误和原始JSON数据（显示"未授权"）。这导致用户误以为链接失效而提交支持工单，实际上他们需要将链接粘贴到专用客户端中。

传统解决方案的弊端： 为每个LLM客户端开发专用连接器/插件不仅耗时费力，还陷入"打地鼠"式的无限更新循环——尤其当越来越多的客户开始开发内部定制客户端时。

创新解决方案： 我们实施了一个巧妙的临时方案： - 当检测到请求为GET /mcp - 且Accept头包含text/html（但不含application/json或text/event-stream） - 则返回HTML页面，明确说明这是MCP服务并指导用户正确添加到客户端

成效显著： - 支持工单数量断崖式下降 - 客户支持部门满意度提升 - 客户配置速度大幅提高 - 无需反复解释"并非所有错误都是故障"

反思： 虽然希望规范本身能解决这类问题，但在AI时代我们只能快速行动，寄望于AI能更快修复问题。

（注：原文中与主题无关的侧边栏内容已省略）

以下是评论内容的总结：

1. 支持MCP解决方案的观点

• 认为通过HTTP头返回HTML页面是合理利用规范 "if the request is for GET /mcp and the Accept header includes text/html...I return a HTML page" (cyberge99) "this is how Kubernetes APIs work" (pvtmert)

2. 对MCP规范的批评

• 认为规范存在不足，特别是在认证和网关方面 "The specification still leaves a lot to be desired, especially as it relates to auth" (eoskx) "utterly terrible attempt at a 'specification'" (epistasis)

3. 关于用户体验的建议

• 建议改进界面设计避免误导点击 "Put it in a monospaced box with a 'copy to clipboard' button" (stavros)
• 支持即时文档展示 "The best documentation is that which is presented at the exact place and time that it is needed" (efitz)

4. 替代方案讨论

• 认为REST API比MCP更灵活 "The entire Rest API specification is a lot more flexible" (didip)
• 建议使用CLI+技能替代 "using clear CLIs + skills instead of MCPs" (unglaublich)

5. 技术实现讨论

• 讨论Accept头处理细节 "how do you handle clients that send Accept: */*?" (xiaosong001)
• 认为这不是hack而是合理使用HTTP规范 "less of a hack and more of discovering what some of the HTTP headers are for" (Waterluvian)

6. 访问问题反馈

• 部分用户反映网站被屏蔽 "site is blocked for me" (JSR_FDED) "first time I see this kind of blocking from Cloudflare" (gpvos)