MCP Hello Page
133 points
• 2 days ago
• Article
Link
作者最近开始为其主要工作工具提供 MCP Server，这次体验很有意思，处在确定性系统与非确定性系统的交汇处。尽管作者认为 MCP 是个设计欠佳的规范，但真正的问题更现实：客户不断反馈服务器"不能用"。原因很简单：用户在浏览器中打开 MCP 端点 URL，会看到 401 Unauthorized 错误和一段原始 JSON 响应，便认为链接坏了，立刻提交工单；实际上他们应该把该 URL 粘贴到自己的 LLM 客户端中。入门引导时没人会想到这一步。
显而易见但代价高的解决方案是把服务器为每个 LLM 客户端打包成连接器或插件——既慢又繁琐，而且容易变成无休止的打地鼠游戏，尤其当越来越多客户在组织内部构建嵌入式客户端时。于是作者采取了更简单、略微取巧的办法：当收到 GET /mcp 请求且 Accept 头包含 text/html 但不包含 application/json 或 text/event-stream 时，服务器返回一页 HTML，说明用户正在用浏览器查看 MCP Server，需要把它添加到他们的客户端。这个小改动效果显著：支持工单大幅减少，客户成功团队更省心，客户上手更快，作者也不用再反复解释并非所有错误信息都是真正的错误。目前尚未观察到负面影响。
作者希望 MCP 规范能内置处理这类用户体验问题，但像当前 AI 时代的常态一样，大家还是快速推进，寄希望于 AI 能比错误积累得更快地修复问题。文章最初写于 2026 年 5 月 16 日，附带侧边栏列有作者主页上的若干个人统计和更新，涵盖从音乐收听习惯到跑步里程及近期写作项目。
The author recently started offering an MCP Server for their main work tool, which has been an interesting experience sitting at the intersection of deterministic and non-deterministic systems. Despite MCP being what they consider a poorly designed specification, the real problem has been practical: customers keep reporting the server isn't working. The issue is straightforward, when users open the MCP endpoint URL in a browser, they get a 401 Unauthorized error with a raw JSON blob. Users see this and immediately file support tickets saying the link is broken, when in reality they need to paste that URL into their LLM client. Nobody thinks that far ahead during onboarding.
The obvious but painful solution would be to package the server as a connector or plugin for every LLM client on the market. This approach is slow, tedious, and becomes an endless game of whack-a-mole, especially as more customers start building their own embedded clients within their organizations. Instead, the author took a simpler, slightly hacky approach. When a request comes in for GET /mcp with an Accept header that includes text/html but not application/json or text/event-stream, the server returns an HTML page explaining that the user is trying to view an MCP server and needs to add it to their client. This small change has been remarkably effective. Support ticket volume has dropped significantly, customer success is happier, customers are getting set up faster, and the author no longer has to explain that not all error messages are actual errors. It is a win all around with no negative side effects observed so far.
The author wishes the MCP specification had built-in handling for this kind of user experience issue, but like everything in the current AI-era landscape, the approach has been to move fast and hope that AI can fix bugs faster than they accumulate. The post was first written on May 16th, 2026, and includes a sidebar with various personal stats and updates from the author's homepage, covering everything from music listening habits to running distances and recent writing projects.
49 comments • Comments Link
- 浏览器请求 /mcp 端点时返回一个 HTML 说明页，通过 HTTP 内容协商（Accept 头）来实现是合理的做法，而不是一种 hack，因为它能恰当地提示用户该资源不适合在浏览器中直接查看。
- MCP 规范在认证方面存在重大空白，过度依赖复杂且不常用的 OAuth 2.0/2.1 功能（如 DCR 和令牌交换）。虽然最近的修订有所改进，但网关可以通过处理令牌交换和访问控制来缓解服务器端的认证负担。
- MCP 中对"网关"的缺乏正式定义导致实现多样，但网关可以作为代理来管理认证、按角色暴露工具并执行上游令牌交换，从而简化后端认证流程。
- MCP Contributors 的 Discord 社区非常活跃，欢迎参与工作组共同改进规范，目前正通过 XAA/ID-JAG 和 CIMD 等标准来解决企业级需求。
- 部分用户即便未使用 VPN，也会因为 Cloudflare 的封锁而无法访问某些网站，说明安全策略可能过于激进，影响了正常访问。
- /mcp 端点的必要性存在争议：带有 Swagger 文档的 REST API 提供更大的灵活性，但 MCP 提供了一致性，对于没有现成 API 的工具仍然有用；也有人更倾向于通过系统提示来调用工具。
- 当客户端的 Accept 头包含 text/html 时返回 HTML 是一种务实的做法，类似 ipinfo.io 和 Kubernetes API 的内容协商方式，但如何处理带通配符（如 Accept: /）的客户端仍需考虑。
- MCP 规范起初设计欠佳且存在损坏链接，这反映了"更差即更好"的采用模式——先占和覆盖率往往胜过质量，这在历史上的技术采用中也曾多次出现。
- 可改进的用户体验细节例如为 MCP URL 提供"复制到剪贴板"按钮而不是可点击链接，以避免用户误点或直接在地址栏打开时产生混淆。
- 将 MCP 服务器打包为特定客户端的连接器违背了 MCP 作为通用协议的初衷，但鉴于当前客户端的限制，这种做法在短期内可能是必要的。 • Returning an HTML explanation page when a browser requests the /mcp endpoint is a reasonable use of HTTP content negotiation via the Accept header, not a hack, as it appropriately informs users that the resource is not meant for direct browser viewing.
• The MCP specification has significant gaps, particularly around authentication, relying on complex and less common OAuth 2.0/2.1 features like DCR and token exchange, though recent revisions are improving this, and gateways can help manage auth by handling token exchange and access control.
• Gateways lack a formal definition in the MCP spec, leading to varied implementations, but they can act as proxies that manage authentication, expose tools based on roles, and perform upstream token exchange, simplifying server-side auth concerns.
• The MCP Contributors Discord is active and welcomes participation in working groups to help evolve the spec, with ongoing efforts to address enterprise needs through standards like XAA/ID-JAG & CIMD.
• Some users face issues accessing certain sites due to Cloudflare blocking, which can occur even without VPN use, highlighting potential overzealous security measures.
• The /mcp endpoint's necessity is questioned, as REST APIs with Swagger docs offer more flexibility, but MCP provides consistency and is useful for tools without existing APIs, though some prefer using system prompts for tool calls.
• Serving HTML when the Accept header includes text/html is a practical approach, similar to how other services like ipinfo.io and Kubernetes APIs handle content negotiation, though handling clients with wildcard Accept headers like `Accept: /` remains a consideration.
• The MCP spec's poor initial design and broken links reflect a "worse is better" adoption pattern, where being first and having reach outweighs quality, similar to historical tech adoptions.
• UX improvements, like providing a copy-to-clipboard button for MCP URLs instead of clickable links, can prevent user confusion, as users naturally click links or paste URLs into address bars.
• Packaging MCP servers as client-specific connectors contradicts MCP's goal of a universal protocol, though it may be necessary due to current client limitations.