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

Bytebase 2025-03-18

551

本文是上期文章的续作：

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

数据库 MCP 服务器仓库地址：https://github.com/bytebase/dbhub

我喜欢的方面‍‍

选择 JSON-RPC 作为 RPC 协议

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

良好的文档

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

文档见：https://modelcontextprotocol.io/introduction
示例见：https://modelcontextprotocol.io/examples

不错的调试工具

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

Inspector 地址：https://modelcontextprotocol.io/docs/tools/inspector

我还使用 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"
      ]
    }
  }
}