用MCPFusion消除分布式SQL管理中的上下文切换

还记得手动扩缩容的旧时光。你会跳进 CLI，检查指标，发现需要加一个节点或调整容量，登录 Web 控制台，在某个专有仪表盘里深挖三层，然后祈祷在找特定集群 ID 的时候没点错地方。

现在我们有 AI Agent 了。但大多数人都用错了。他们把 Claude 或 Cursor 当作更好的代码搜索引擎，而不是给它们装上"手"。

如果你在 TiDB Cloud 上跑高可用工作负载，瓶颈不在写 SQL——你已经知道怎么写了。瓶颈在于运维可视化：不用离开 IDE 就能知道 Serverless 实例和专属集群到底在发生什么。

代码与基础设施之间的鸿沟

我花这么多时间构建 MCPFusion 就是因为这个脱节。LLM 可能能帮你写出一个复杂的 JOIN，但如果它不知道目标 TiDB X 实例是否真的健康，或者哪个项目 ID 处理你的预发环境，它基本上是在蒙眼飞行。

你最后只能把终端里的 JSON 片段复制粘贴到聊天窗口里，就为了给模型一点上下文。这很慢，容易出错，说实话，配不上现代工具该有的样子。

这就是我们在 Vinkius 上发布 TiDB Cloud (Serverless Distributed SQL) MCP server 的原因。它把这个闭环补上了。

这玩意实际做什么（又不做什么）

咱们把这款工具通过 Claude 或 Cursor 这样的 Agent 能做什么说得非常清楚。不是在找"魔法"，我们要的是可预测的实用性。

当前实现聚焦在发现和检查上。用 DevOps 的话说，它提供了拓扑结构的受控只读视图。以下是可用的功能：

组织发现：你可以调用 list_projects 查看伞下所有项目，并通过 get_project 拉取元数据。这就直接解决了"那个项目 ID 是什么来着"的问题。

层级感知：你可以用 list_instances（拉取 TiDB X 实例，包括 Starter、Essential 和 Premium）和 list_clusters（针对 Dedicated 配置）来区分 Serverless 组件和重型实例。

拓扑审计：不用在 UI 里点来点去验证配置了，你直接问："给我项目 103 里 Dedicated 集群的详情。" Agent 调用内部工具回报节点数（TiKV/TiDB）和健康状态。

人们第一次玩 MCP 时常犯的一个错误是以为马上就能执行破坏性操作。为了保持生产级和安全——尤其考虑到我用 V8 沙箱执行上下文做安全的方式——这个特定的 server 被限制为只读操作。你不会因为 LLM 幻觉出一个删除命令就意外清掉一个生产集群。它只能识别项目、列出实例、监控集群。

工作流对比

老方式：

打开浏览器 -> 登录 TiDB Cloud
导航到项目 -> 找到集群 -> 记录实例状态/ID
切换到 VS Code -> 写查询/配置
发现 ID 错了 -> 重复第一步

新方式：

"嘿 Claude，给我看看 Production 项目里所有的 TiDB X 实例，我要检查它们的区域状态。"
（Agent 执行 list_projects，找到 ID，执行 list_instances，报告结果。）
"好的，现在告诉我我的 'Analytics-Main' Dedicated 集群是否有足够的节点正常工作。"
（Agent 执行 list_clusters，解析响应。）

一切都在你实际工作的上下文中发生。

大多数人在浏览文档时忽略的一个关键细节是，个体单元和整体架构之间的桥接有多容易。因为这同时集成了 list_instances（TiDB X）和 list_clusters（Dedicated 构建），你不需要被迫用单一心智模型来看"我的 DB 长什么样"。你通过一个统一的对话界面同时处理 Serverless 的灵活性和 Dedicated 的稳定性。

engineer 可靠性意味着减少熵。减少熵通常意味着减少人类需要在两个系统（控制台 → IDE）之间手动转换信息的次数。通过 Agent 让基础设施可观测不是在偷懒；而是在关键部署窗口期间保持专注。当然，如果你更喜欢通过某些企业 GUI 手动操作，让 Agent 通过 MCP 这种专用协议辅助你的工作流，那也没问题。

MCP 是 AI Agent 的音乐。我们建了目录。去发现 Vinkius MCP Catalog。

---