一份精心策划并带有个人见解的 Model Context Protocol (MCP) 最佳实践列表,涉及构建 MCP 服务器和 MCP 客户端。
待定
使用一致且兼容的命名约定来命名您的 MCP 服务器 工具,以确保它们可以被 MCP 客户端正确发现和调用。
get Npm Package Infoget.Npm.Package.Infoget(Npm)PackageInfogetNpmPackageInfoget-npm-package-infoget_npm_package_infoserver.tool(
"getNpmPackageInfo",
"获取 npm 包的信息",
{
packageName: z.string()
},
async ({ packageName }) => {
// 实现细节...
return {
content: [{ type: "text", text: output }],
};
}
);
使用非标准的命名约定可能会阻止或干扰 MCP 客户端正确地发现和展示您的工具给最终用户。GPT-4o 分词器在处理 camelCase 命名约定时效果最佳。
在实现搜索类型工具时,即使没有精确匹配,也应避免返回明确的“未找到”消息。
// 不要这样做
if (!exactMatch) {
return {
content: [
{
type: "text",
text: `模块 ${query} 未找到。以下是所有可用模块:${allModules}`
}
]
};
}
// 而是这样做
return {
content: [
{
type: "text",
text: `以下是一些可能有助于您查询的可用模块:${relevantModules}`
}
]
};
让大语言模型(LLM)根据提供的数据自行判断相关性,而不是在工具响应中过早地宣告失败。负面陈述如“未找到”可能会过度影响 LLM,使其忽略随后的有用信息。通过提供相关数据而不进行负面描述,您可以使 LLM 正确地处理和利用所有可用信息。
这种方法并不适用于所有场景。在处理敏感数据(如用户信息)时,安全性和隐私问题应优先于提供替代数据。
将您的 MCP 服务器作为 Docker 容器部署,以消除环境设置挑战,并确保跨不同系统的一致运行。
MCP 服务器通常需要特定的运行时环境(Node.js、Python),以及特定版本和依赖项。Docker 抽象了这些需求,将复杂的设置指令简化为一个简单的容器运行命令。
示例 Dockerfile 实现以打包 MCP 服务器:
FROM node:18-slim
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
用户按如下方式运行它:
docker run -p 3000:3000 your-mcp-server-image
确保您的 MCP 服务器不受第三方依赖项中的已知漏洞的影响,以满足安全要求并促进组织采用。
MCP 服务器通常需要广泛的访问和集成能力,因此任何漏洞都可能成为重大安全风险。组织的 IT 和安全团队会在批准采用之前仔细审查这些依赖项。