MCP Server 实现笔记：开发者视角下的优缺点

本文是上期文章的续作：

基于我使用 TypeScript 实现数据库 MCP 服务器的经验撰写。

我喜欢的方面

选择 JSON-RPC 作为 RPC 协议

MCP 的两个可行选项是 JSON-RPC 和 gRPC。我庆幸 MCP 选择了前者。 虽然 gRPC 效率更高，但基于 JSON 的纯文本协议更容易上手。这种易用性对于 MCP 获得广泛采用很重要。

良好的文档

MCP 文档清晰明了，有不少的示例展示了实际实现。

不错的调试工具

Inspector 非常有价值。除了排查问题外，我还用 Inspector 更好地理解 MCP 概念。

我还使用 Claude Desktop 进行端到端测试。虽然整个开发周期（构建、重启 Claude Desktop、测试、修复代码）可以更流畅，但拥有完整的本地调试环境比对远程服务进行调试更高效。

我遇到的困难

Transport 的复杂性

我认为 Transport 只要提供 sse 就足够了。增加额外的 stdio 传输引入了几个复杂因素：

首先，两种方法的生命周期管理不同。使用 stdio 时，MCP 客户端管理 MCP 服务器生命周期（例如，调试时，Inspector 启动 MCP 服务器）。对于 sse，MCP 服务器管理自己的生命周期（例如，MCP 服务器和 Inspector 单独启动，之后 Inspector 指向 MCP 服务器端点）。

我认为大多数正式的 MCP 服务器需要管理自己的生命周期，特别是当需要单独配置时。

使用 stdio 作为通信通道也有问题。它迫使开发者使用 console.error 而不是 console.log 进行调试。此外，如果 MCP Server 依赖的库无意中写入 stdio，那就毫无办法了。

虽然我还没有实现过 MCP 客户端，但我怀疑支持两种传输类型也会使客户端实现变得复杂。

路由限制

我发现 MCP Host 如何将命令路由到适当的 [MCP 服务器，工具] 组存在设计问题。

我的数据库 MCP 服务器实现接受 DSN 连接到数据库：

{
  "mcpServers": {
    "dbhub": {
      "command": "npx",
      "args": [
        "-y",
        "@bytebase/dbhub",
        "--transport",
        "stdio",
        "--dsn",
        "postgres://postgres:postgres@localhost:5432/dbname?sslmode=disable"
      ]
    }
  }
}

这种方法有两个问题：

1. 用户必须为每个数据库连接加载一个新的 DBHub 服务器，这导致 Claude Desktop 中出现重复的工具命令。
2. 虽然我可以修改实现以允许 DBHub 处理多个数据库，但仍不清楚如何指示 MCP 主机将 Prompt 路由到特定所需的数据库。

Claude Desktop 的限制

1. 在开发过程中，必须重启 Claude Desktop 来加载新的 MCP 服务器很烦人。
2. Claude Desktop 仅支持 stdio Transport，这迫使我不得不在服务器中实现 stdio 支持。
3. 我发现了一个 bug。

展望未来

尽管有这些挑战，我对 MCP 的当前状态仍然满意，并对其未来持乐观态度。 官方路线图概述了它前景广阔的发展，其中对我特别有吸引力的是：

Hierarchical Agent Systems: Improved support for trees of agents through namespacing and topology awareness

这一功能可以解决我遇到的路由限制，并为 MCP 开发者提供改进的调试功能。

我目前最大的担忧是核心 MCP 团队似乎人手严重不足。生态系统正在发展，新问题正在迅速积累。他们需要更多的帮手。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase