在写完《MCP Server》那篇文章后我接了个新需求：让同一个 Agent 同时调用两个 MCP Server——一个查询 SQLite 数据库，另一个访问本地文件程序。不过，Agent 运行了一轮后返回的答案让我怀疑：它居然把文件程序里的“张三”当成了使用者想要的数据库订单记录。

这并不是 Server 写错了也不是模型不行，而是 AI 调错了 Tool。

两个 Server 都实现了 search 方法，AI 却选用了文件程序的 search本该调用数据库的 query。这让我真正明白 MCP Client 的意义——它不是简单的“连接器”，而是把多组 Server 能力「翻译」成 AI 能正确理解和选择的语言。话说回来，

Client 到底是干什么的

先用最简洁的方式厘清角色分工：

MCP Server 只负责“我有这个能力”。而 MCP Client 决定“AI 怎么知道该用哪个”。当你手里拥有两个以上 Server 时这种区分直接决定 AI 是否会走神。

翻车现场还原

场景复盘：

• 本地启动两个 Node.js Server：
  • db-server.mjs: 暴露search、query、insert
  • file-server.mjs: 暴露search、read、write
• 编写一个 Client 把它们连起来。其实，再看代码如下，

import { Client } from '@modelcontextprotocol/sdk/client/index.js';import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';const dbClient = new Client;const fileClient = new Client;其实，await dbClient.connect(
new StdioClientTransport
);await fileClient.connect(
new StdioClientTransport
);// 列出各 Server 的 Tool
const dbTools = await dbClient.listTools;const fileTools = await fileClient.listTools;

The code looks fine—two independent Clients,each talking to its own Server. The problem surfaces on AI side.

L​LM receives a merged tool list that looks like this:

可用工具的观点是。- search
- query
- insert
- search
- read
- write

Pain point： 同名的 searchsearch

MCP 协议并不强制 Tool 名称唯一，碰撞在实际项目中极为常见。LLM 在做工具选择时主要依据Name + Description**。当两者几乎相同，模型很容易走偏。

class NamespaceClient {
constructor {
this.namespace = namespace;this.client = client;}
async listTools {
const tools = await this.client.listTools;话说回来，return tools.map(tool => ({
...tool。name: `${this.namespace}_${tool.name}`,description: ` ${tool.description}`
}));}
async callTool {
const originalName = name.replace;return this.client.callTool;}
}
// 包装原始 Client
const dbClient = new NamespaceClient;const fileClient = new NamespaceClient;老实说，// AI now sees:
// - db_search
// - db_query
// - db_insert
// - fs_search
// - fs_read
// - fs_write