尧图网页设计 
1. 从“各自为战”到“通用对话”为什么我们需要 MCP最近在折腾 AI Agent 项目一个绕不开的痛点就是“工具集成”。你想让 Agent 去查天气、读数据库、控制智能家居或者调用某个内部 API就得为它写一个专门的“适配器”。每个工具一套逻辑每个模型比如 Claude、GPT对接方式还不一样很快你就会陷入“胶水代码”的泥潭项目变得臃肿且难以维护。这感觉就像你家里有十几个不同品牌、不同接口的智能电器每个都得配一个专属遥控器。你想实现“一句话关掉所有灯”就得先拿起 A 品牌的遥控器再拿起 B 品牌的 App手忙脚乱。MCPModel Context Protocol的出现就是为了解决这个“遥控器泛滥”的问题。它本质上是一个协议标准目标是在 AI 模型尤其是大语言模型和外部工具、数据源之间建立一套统一的“对话”语言。你可以把它想象成智能家居领域的Matter 协议或者软件领域的USB-C 接口。Matter 让不同品牌的灯泡、插座能通过一个标准协议被同一个智能中枢控制USB-C 让手机、电脑、耳机都能用同一根线充电和传输数据。MCP 想做的是同样的事情定义一套 AI 模型如何“发现”工具、“理解”工具能力、“安全调用”工具的规范。一旦工具都遵循 MCP 标准那么任何一个兼容 MCP 的 AI 模型或 Agent 框架就能像即插即用一样轻松调用所有这些工具无需再为每个工具单独编写集成代码。这不仅仅是方便了开发者。更重要的是它极大地释放了 AI Agent 的能力边界。一个 Agent 不再受限于其内置的少数功能而是可以通过 MCP 动态接入一个不断增长的“工具生态”。今天它可以帮你分析数据库明天接入一个股票行情接口后天又连上了公司的项目管理软件而 Agent 本身的核心逻辑几乎不用改动。这就是标题里所说的“万能接口”标准的含义——它不是某一个具体的 API而是一套让 AI 与万物互联的“元协议”。2. MCP 协议核心三要素资源、工具与提示词模板要理解 MCP 如何工作我们需要拆解它的三个核心概念资源Resources、工具Tools和提示词模板Prompts。这三者共同构成了 MCP Server 向 AI 模型Client暴露的能力菜单。2.1 资源Agent 的“可读文件”资源是 MCP 中最基础的概念。它代表一系列可供 AI 模型读取的结构化数据或文本内容。注意这里的“读取”是只读的。资源可以是静态的也可以是动态生成的。举个例子一个数据库表的结构定义可以作为一个资源告诉 Agent 这个表有哪些字段、什么类型。一份实时更新的日志文件Server 可以提供一个资源其内容是最新的 100 条日志。一个网页的摘要Server 可以抓取某个 URL将其内容作为资源提供给 Agent。你公司的项目清单一个内部 API 返回的 JSON 数据通过 MCP 资源的形式暴露。在协议层面Server 会向 Client 宣告自己提供了哪些资源。每个资源有一个唯一的uri如file:///logs/app.log或db://schema/users和一个mimeType如text/plainapplication/json。当 AI 模型需要了解某个信息时它可以向 Server 请求读取resources/read对应的资源。Server 则负责在背后执行真正的读取操作读文件、查数据库、调 API并将结果以文本或结构化数据的形式返回。为什么设计“资源”这个概念它巧妙地将“数据获取”这个动作标准化了。无论底层数据来自哪里对 AI 模型来说它只需要发起一个统一的“读资源”请求。这避免了 AI 模型需要理解五花八门的 API 签名和认证方式。2.2 工具Agent 的“可执行命令”如果说资源是让 Agent“看”那么工具就是让 Agent“做”。工具代表一个可供 AI 模型调用的执行函数它可能有输入参数也可能会产生副作用比如写入数据、发送消息、执行命令。典型的工具例子execute_sql执行一条 SQL 查询。send_email发送一封邮件参数包括收件人、主题、正文。create_calendar_event在日历中创建一个新事件。get_weather获取某个城市的天气。在 MCP 中Server 会以标准化的 JSON Schema 格式描述每个工具工具名、描述、以及输入参数的详细定义类型、是否必需、描述等。当 AI 模型决定要执行某个操作时它会构造符合该 Schema 的参数并向 Server 发起工具调用tools/call请求。Server 执行实际逻辑然后将结果或错误返回给 Client。工具与资源的联动是常见模式。例如Agent 可能先读取一个“数据库 schema”资源来了解表结构然后再调用execute_sql工具进行查询。MCP 协议本身并不规定这种逻辑它只是提供了这两种能力的标准化接口具体的协作逻辑由 AI 模型或背后的 Orchestrator来决策。2.3 提示词模板Agent 的“对话预设”这是 MCP 中一个非常实用且常被忽略的特性。提示词模板允许 Server 预定义一些常用的、结构化的提示词片段供 AI 模型直接使用或组合。比如一个代码库分析的 MCP Server 可以定义以下模板review_code_snippet模板内容可能是“请以资深工程师的身份评审以下代码{{code}}。重点关注代码风格、潜在 bug 和性能问题。”explain_error_log模板内容可能是“以下是应用程序的错误日志{{log}}。请分析可能的原因并提供排查步骤。”当 Client 列出可用的提示词模板后它可以直接请求某个模板的渲染结果prompts/get并传入所需的变量如code或log。Server 返回渲染好的、可直接投入 AI 模型对话的提示词文本。这个设计的好处是什么它把领域特定的、优化的提示词工程Prompt Engineering工作下沉到了工具提供方Server。作为 Agent 开发者你不需要自己琢磨怎么问 SQL 数据库最好数据库 MCP Server 的作者已经为你设计好了专业的提示词模板。这提升了交互质量也降低了使用门槛。3. 协议层剖析MCP 如何实现通信与安全MCP 是一个应用层协议它不关心底层用什么传输。实际上它支持多种传输方式Transport最常见的是stdio标准输入输出和SSEServer-Sent Events。这赋予了它极大的部署灵活性。3.1 通信模型基于 JSON-RPC 的消息交换无论底层传输是什么MCP 上层的消息格式都遵循JSON-RPC 2.0规范。这是一个轻量级的远程过程调用协议。简单来说Client 和 Server 之间通过交换 JSON 消息来进行“请求-响应”或“通知”。一个典型的工作流如下初始化Initialize连接建立后Client 首先发送initialize请求携带自己的元数据如支持的能力。Server 回复initialize_result并附上自己提供的资源、工具、提示词模板的列表。这是“能力协商”阶段。列出清单ListingClient 可以发送tools/list、resources/list、prompts/list请求获取详细的能力描述。执行操作Execution当 AI 模型需要读取数据时发送resources/read请求。当需要执行操作时发送tools/call请求。当需要提示词时发送prompts/get请求。通知NotificationServer 可以主动向 Client 发送通知。例如当某个资源的内容发生变化时如日志文件更新了Server 可以发送resources/updated通知Client 可以据此决定是否重新读取。这是一个非常重要的特性使得 MCP 能支持一定程度的实时数据流。为什么选择 JSON-RPC因为它简单、通用、语言无关。几乎任何编程语言都有成熟的 JSON-RPC 库这使得实现 MCP 的 Client 或 Server 变得相对容易。消息是纯文本的 JSON也便于调试和日志记录。3.2 安全与权限尚未标准化但至关重要目前MCP 协议规范本身并没有强制规定身份验证和授权机制。这是一个“将复杂性下放”的设计选择同时也意味着安全需要由实现者来保障。这在实际部署中是一个必须严肃对待的问题。常见的几种安全实践模式传输层安全如果使用 SSE over HTTP那么可以利用 HTTPS、HTTP 基本认证、API 密钥等现有的 Web 安全机制。Server 可以在初始化阶段验证 Client 的身份。进程隔离与信任边界在 stdio 模式下MCP Server 通常作为一个子进程被 MCP Client如 Claude Desktop启动。此时安全模型依赖于操作系统进程间的信任关系。谁有权启动这个 Server 进程就成了关键。这种方式适合本地、可信环境下的工具扩展。Server 内部实现权限控制这是最核心的一层。即使连接建立了MCP Server 在实现每一个工具如execute_sql和资源如read_database时内部也应该进行权限检查。例如一个 Server 可以映射到数据库的只读用户那么即使 Agent 请求DROP TABLE底层的数据库用户也没有权限执行。输入验证与净化MCP Server 必须对所有来自 Client 的输入特别是工具调用的参数进行严格的验证和净化防止注入攻击。例如对于 SQL 执行工具更安全的做法是只允许执行预定义的查询语句或存储过程而不是接受任意的 SQL 字符串。注意在评估或使用一个 MCP Server 时务必审查其安全设计。一个暴露了shell_exec工具且没有权限控制的 Server 是极其危险的。对于生产环境建议将 MCP Server 部署在独立的、网络隔离的容器中并通过严格的网络策略和身份认证来访问。4. 实战从零构建一个简单的 MCP Server理论说得再多不如动手写一个。我们以构建一个“系统信息查询” MCP Server 为例它提供一个资源只读的实时系统负载和一个工具获取指定目录的文件列表。我们将使用TypeScript和官方modelcontextprotocol/sdk来实现。4.1 环境准备与项目初始化首先确保你安装了 Node.js版本 18和 npm。然后创建一个新目录并初始化项目mkdir my-system-mcp-server cd my-system-mcp-server npm init -y npm install modelcontextprotocol/sdk npm install -D typescript ts-node types/node npx tsc --init在package.json中添加一个启动脚本{ scripts: { start: ts-node src/index.ts } }4.2 核心 Server 实现创建src/index.ts文件开始编写 Server 逻辑。import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { CallToolRequestSchema, ListResourcesRequestSchema, ListToolsRequestSchema, ReadResourceRequestSchema, } from modelcontextprotocol/sdk/types.js; import os from os; import fs from fs/promises; import path from path; // 1. 创建 Server 实例 const server new Server( { name: my-system-mcp-server, version: 0.1.0, }, { capabilities: { // 声明我们支持哪些能力 resources: {}, // 支持资源 tools: {}, // 支持工具 // prompts: {}, // 本例暂不实现提示词模板 }, } ); // 2. 定义并注册“系统负载”资源 const SYSTEM_LOAD_URI system://loadavg; server.setRequestHandler(ListResourcesRequestSchema, async () { return { resources: [ { uri: SYSTEM_LOAD_URI, mimeType: application/json, name: 系统平均负载, description: 获取过去1、5、15分钟的系统平均负载。, }, ], }; }); server.setRequestHandler(ReadResourceRequestSchema, async (request) { if (request.params.uri SYSTEM_LOAD_URI) { const loadavg os.loadavg(); // [1min, 5min, 15min] return { contents: [ { uri: SYSTEM_LOAD_URI, mimeType: application/json, // 将负载数据以 JSON 字符串形式返回 text: JSON.stringify({ load_1min: loadavg[0], load_5min: loadavg[1], load_15min: loadavg[2], cores: os.cpus().length, timestamp: new Date().toISOString(), }, null, 2), }, ], }; } throw new Error(Resource not found: ${request.params.uri}); }); // 3. 定义并注册“列出文件”工具 server.setRequestHandler(ListToolsRequestSchema, async () { return { tools: [ { name: list_directory, description: 列出指定目录下的文件和文件夹。, inputSchema: { type: object, properties: { directoryPath: { type: string, description: 要列出的目录路径。默认为当前工作目录。, }, }, required: [], // directoryPath 不是必需的 }, }, ], }; }); server.setRequestHandler(CallToolRequestSchema, async (request) { if (request.params.name list_directory) { const args request.params.arguments as { directoryPath?: string }; const targetDir args.directoryPath || process.cwd(); // 简单的安全校验防止目录遍历攻击非常基础版 const resolvedPath path.resolve(targetDir); if (!resolvedPath.startsWith(process.cwd())) { throw new Error(出于安全考虑只能列出当前工作目录及其子目录。); } try { const items await fs.readdir(resolvedPath, { withFileTypes: true }); const list items.map((item) ({ name: item.name, type: item.isDirectory() ? directory : file, isDirectory: item.isDirectory(), isFile: item.isFile(), })); return { content: [ { type: text, text: 目录 ${targetDir} 下的内容\n${JSON.stringify(list, null, 2)}, }, ], }; } catch (error: any) { return { content: [ { type: text, text: 错误无法读取目录 ${targetDir}。原因${error.message}, }, ], isError: true, }; } } throw new Error(Tool not found: ${request.params.name}); }); // 4. 启动 Server使用 stdio 传输 async function main() { const transport new StdioServerTransport(); await server.connect(transport); console.error(MCP System Info Server running on stdio...); } main().catch((error) { console.error(Server error:, error); process.exit(1); });4.3 运行与测试首先编译并运行你的 Servernpm start此时 Server 会挂起等待通过 stdin/stdout 接收来自 Client 的 JSON-RPC 消息。要测试它我们需要一个 MCP Client。最方便的是使用Claude Desktop如果已经配置了 MCP 支持或者使用一个简单的测试脚本。这里我们用官方 SDK 自带的简单测试方法创建一个test_client.tsimport { Client } from modelcontextprotocol/sdk/client/index.js; import { StdioClientTransport } from modelcontextprotocol/sdk/client/stdio.js; import { spawn } from child_process; async function test() { // 启动 Server 进程 const serverProcess spawn(ts-node, [src/index.ts], { stdio: [pipe, pipe, inherit] // 将 stderr 继承到控制台以便调试 }); // 创建 Transport 和 Client const transport new StdioClientTransport({ command: echo, // 占位符实际进程已启动 args: [], process: serverProcess // 直接传入已启动的进程 }); const client new Client( { name: test-client, version: 0.1.0, }, { capabilities: {}, } ); await client.connect(transport); // 测试1列出资源 console.log( Listing Resources ); const resources await client.listResources(); console.log(JSON.stringify(resources, null, 2)); // 测试2读取系统负载资源 console.log(\n Reading System Load Resource ); const loadData await client.readResource({ uri: system://loadavg }); console.log(loadData.contents[0].text); // 测试3列出工具 console.log(\n Listing Tools ); const tools await client.listTools(); console.log(JSON.stringify(tools, null, 2)); // 测试4调用 list_directory 工具 console.log(\n Calling list_directory Tool ); const result await client.callTool({ name: list_directory, arguments: { directoryPath: ./ }, }); console.log(result.content[0].text); await client.close(); serverProcess.kill(); } test().catch(console.error);运行测试脚本npx ts-node test_client.ts。你应该能看到 Server 返回的系统负载信息和当前目录的文件列表。4.4 集成到 Claude Desktop要让这个 Server 真正被 AI 使用可以将其集成到 Claude Desktop 中。这通常需要在 Claude Desktop 的配置文件中添加 MCP Server 的设置。找到 Claude Desktop 的配置目录例如在 macOS 上是~/Library/Application Support/Claude/claude_desktop_config.json添加如下配置{ mcpServers: { my-system-server: { command: node, args: [/ABSOLUTE/PATH/TO/YOUR/PROJECT/build/index.js], // 指向你编译后的 JS 文件 env: {} } } }重启 Claude Desktop 后Claude 就能“看到”并使用你编写的list_directory工具和system://loadavg资源了。你可以直接问它“当前系统负载高吗”或者“帮我列出项目根目录下的文件。”实操心得错误处理是关键在callTool和readResource的处理函数中务必进行充分的错误捕获和用户友好的错误信息返回。将底层错误如文件不存在、权限不足转化为 AI 模型能理解的文本。描述要清晰工具和资源的description字段至关重要。AI 模型依赖这些描述来决定何时使用它们。描述应简洁、准确地说明功能、输入和输出。安全是底线我们这个示例中的路径安全检查非常基础。在生产环境中你需要更严格的策略比如配置允许访问的目录白名单、验证用户身份等。永远不要相信来自 Client 的未经净化的输入。5. MCP 生态现状、挑战与未来展望MCP 自推出以来发展迅速但其生态仍处于早期阶段机遇与挑战并存。5.1 当前生态概览目前MCP 生态主要围绕以下几个方向展开官方与核心 ServerAnthropic 官方维护了一些基础 Server如filesystem文件系统、postgres数据库、brave-search搜索等展示了协议的最佳实践。第三方工具集成社区已经创建了大量 Server将流行的开发工具、云服务、数据源接入 MCP。例如GitHub / GitLab管理仓库、查看 Issue、提交 PR。Jira / Linear项目管理与任务查询。Datadog / Sentry查看监控指标和错误日志。AWS / GCP / Azure云资源查询与管理需谨慎处理权限。Notion / Slack读写知识库和发送消息。Client 端支持Claude Desktop目前对 MCP 支持最完善、体验最好的客户端是许多用户接触 MCP 的入口。Cursor IDE / Windsurf这些 AI 原生编辑器开始集成 MCP允许 AI 助手在编码时直接调用外部工具。自定义 Agent 框架开发者可以在自己的 AI Agent 应用中嵌入 MCP Client SDK使其具备动态扩展工具的能力。5.2 面临的主要挑战尽管前景广阔MCP 在普及过程中也面临一些现实挑战安全与权限模型的缺失如前所述协议层缺乏强制性的安全标准。这导致每个 Server 需要自行实现一套权限体系增加了开发复杂性和安全审计的难度。企业级应用尤其需要清晰的租户隔离、角色权限控制和审计日志。工具发现的“冷启动”问题一个 Agent 如何知道该连接哪个 MCP Server目前多靠手动配置。未来可能需要一个“Server 注册中心”或“能力发现服务”让 Agent 能动态发现并请求接入所需的工具。复杂交互与状态管理MCP 目前的工具调用是“单次请求-响应”模式。对于需要多轮交互的复杂任务例如引导用户完成一个多步骤的配置流程支持还不够好。这需要扩展协议或由上层 Orchestrator 来管理会话状态。性能与稳定性MCP Server 通常作为独立进程运行频繁的进程间通信IPC可能带来延迟。对于高并发或低延迟要求的场景需要优化传输层或采用更高效的通信方式。标准化与碎片化风险虽然 MCP 旨在统一但如果各大厂商如 OpenAI、Google都推出自己的“类似但不同”的 Agent 工具协议生态可能会碎片化。MCP 需要更广泛的行业采纳来避免这一问题。5.3 未来可能的演进方向从我个人的观察和项目实践来看MCP 及其代表的方向可能会朝以下几个方面演进协议分层与专业化可能会出现更细分的协议层。例如基础 MCP 定义核心通信而针对“数据库操作”、“云资源控制”、“企业内部系统”等特定领域会衍生出更精确、包含领域语义的“Profile”或“扩展”。与 Agent 框架深度集成像 LangChain、LlamaIndex、AutoGen 这样的 Agent 框架可能会将 MCP Client 作为一级公民集成。开发者可以直接在框架中配置 MCP Server 地址框架自动处理工具调用、资源读取和提示词组合。“可观测性”与“调试”工具随着 MCP 网络变得复杂对 MCP 通信进行监控、调试和记录的需求会激增。未来可能会出现专门的 MCP 流量分析工具帮助开发者理解 Agent 的决策链条和工具使用情况。边缘与本地优先出于数据隐私和延迟考虑很多 MCP Server 会部署在本地或边缘网络。MCP 的轻量级和进程隔离特性非常适合这种场景推动 AI 能力向终端下沉。最后再分享一个小技巧在规划你自己的 MCP Server 时不妨从“资源”入手而不是“工具”。因为提供只读的“资源”通常更安全也更容易让 AI 模型理解。先让 Agent 能“看到”你的数据世界再逐步、谨慎地开放“执行”能力。例如先做一个能暴露项目代码结构、API 文档、日志摘要的 Server观察 AI 如何利用这些信息再考虑是否开放创建工单、执行部署等写操作工具。这种渐进式的开放能让你在享受 MCP 便利的同时更好地控制风险。 MCP协议：AI Agent的统一工具集成标准与实战指南
1. 从“各自为战”到“通用对话”为什么我们需要 MCP最近在折腾 AI Agent 项目一个绕不开的痛点就是“工具集成”。你想让 Agent 去查天气、读数据库、控制智能家居或者调用某个内部 API就得为它写一个专门的“适配器”。每个工具一套逻辑每个模型比如 Claude、GPT对接方式还不一样很快你就会陷入“胶水代码”的泥潭项目变得臃肿且难以维护。这感觉就像你家里有十几个不同品牌、不同接口的智能电器每个都得配一个专属遥控器。你想实现“一句话关掉所有灯”就得先拿起 A 品牌的遥控器再拿起 B 品牌的 App手忙脚乱。MCPModel Context Protocol的出现就是为了解决这个“遥控器泛滥”的问题。它本质上是一个协议标准目标是在 AI 模型尤其是大语言模型和外部工具、数据源之间建立一套统一的“对话”语言。你可以把它想象成智能家居领域的Matter 协议或者软件领域的USB-C 接口。Matter 让不同品牌的灯泡、插座能通过一个标准协议被同一个智能中枢控制USB-C 让手机、电脑、耳机都能用同一根线充电和传输数据。MCP 想做的是同样的事情定义一套 AI 模型如何“发现”工具、“理解”工具能力、“安全调用”工具的规范。一旦工具都遵循 MCP 标准那么任何一个兼容 MCP 的 AI 模型或 Agent 框架就能像即插即用一样轻松调用所有这些工具无需再为每个工具单独编写集成代码。这不仅仅是方便了开发者。更重要的是它极大地释放了 AI Agent 的能力边界。一个 Agent 不再受限于其内置的少数功能而是可以通过 MCP 动态接入一个不断增长的“工具生态”。今天它可以帮你分析数据库明天接入一个股票行情接口后天又连上了公司的项目管理软件而 Agent 本身的核心逻辑几乎不用改动。这就是标题里所说的“万能接口”标准的含义——它不是某一个具体的 API而是一套让 AI 与万物互联的“元协议”。2. MCP 协议核心三要素资源、工具与提示词模板要理解 MCP 如何工作我们需要拆解它的三个核心概念资源Resources、工具Tools和提示词模板Prompts。这三者共同构成了 MCP Server 向 AI 模型Client暴露的能力菜单。2.1 资源Agent 的“可读文件”资源是 MCP 中最基础的概念。它代表一系列可供 AI 模型读取的结构化数据或文本内容。注意这里的“读取”是只读的。资源可以是静态的也可以是动态生成的。举个例子一个数据库表的结构定义可以作为一个资源告诉 Agent 这个表有哪些字段、什么类型。一份实时更新的日志文件Server 可以提供一个资源其内容是最新的 100 条日志。一个网页的摘要Server 可以抓取某个 URL将其内容作为资源提供给 Agent。你公司的项目清单一个内部 API 返回的 JSON 数据通过 MCP 资源的形式暴露。在协议层面Server 会向 Client 宣告自己提供了哪些资源。每个资源有一个唯一的uri如file:///logs/app.log或db://schema/users和一个mimeType如text/plainapplication/json。当 AI 模型需要了解某个信息时它可以向 Server 请求读取resources/read对应的资源。Server 则负责在背后执行真正的读取操作读文件、查数据库、调 API并将结果以文本或结构化数据的形式返回。为什么设计“资源”这个概念它巧妙地将“数据获取”这个动作标准化了。无论底层数据来自哪里对 AI 模型来说它只需要发起一个统一的“读资源”请求。这避免了 AI 模型需要理解五花八门的 API 签名和认证方式。2.2 工具Agent 的“可执行命令”如果说资源是让 Agent“看”那么工具就是让 Agent“做”。工具代表一个可供 AI 模型调用的执行函数它可能有输入参数也可能会产生副作用比如写入数据、发送消息、执行命令。典型的工具例子execute_sql执行一条 SQL 查询。send_email发送一封邮件参数包括收件人、主题、正文。create_calendar_event在日历中创建一个新事件。get_weather获取某个城市的天气。在 MCP 中Server 会以标准化的 JSON Schema 格式描述每个工具工具名、描述、以及输入参数的详细定义类型、是否必需、描述等。当 AI 模型决定要执行某个操作时它会构造符合该 Schema 的参数并向 Server 发起工具调用tools/call请求。Server 执行实际逻辑然后将结果或错误返回给 Client。工具与资源的联动是常见模式。例如Agent 可能先读取一个“数据库 schema”资源来了解表结构然后再调用execute_sql工具进行查询。MCP 协议本身并不规定这种逻辑它只是提供了这两种能力的标准化接口具体的协作逻辑由 AI 模型或背后的 Orchestrator来决策。2.3 提示词模板Agent 的“对话预设”这是 MCP 中一个非常实用且常被忽略的特性。提示词模板允许 Server 预定义一些常用的、结构化的提示词片段供 AI 模型直接使用或组合。比如一个代码库分析的 MCP Server 可以定义以下模板review_code_snippet模板内容可能是“请以资深工程师的身份评审以下代码{{code}}。重点关注代码风格、潜在 bug 和性能问题。”explain_error_log模板内容可能是“以下是应用程序的错误日志{{log}}。请分析可能的原因并提供排查步骤。”当 Client 列出可用的提示词模板后它可以直接请求某个模板的渲染结果prompts/get并传入所需的变量如code或log。Server 返回渲染好的、可直接投入 AI 模型对话的提示词文本。这个设计的好处是什么它把领域特定的、优化的提示词工程Prompt Engineering工作下沉到了工具提供方Server。作为 Agent 开发者你不需要自己琢磨怎么问 SQL 数据库最好数据库 MCP Server 的作者已经为你设计好了专业的提示词模板。这提升了交互质量也降低了使用门槛。3. 协议层剖析MCP 如何实现通信与安全MCP 是一个应用层协议它不关心底层用什么传输。实际上它支持多种传输方式Transport最常见的是stdio标准输入输出和SSEServer-Sent Events。这赋予了它极大的部署灵活性。3.1 通信模型基于 JSON-RPC 的消息交换无论底层传输是什么MCP 上层的消息格式都遵循JSON-RPC 2.0规范。这是一个轻量级的远程过程调用协议。简单来说Client 和 Server 之间通过交换 JSON 消息来进行“请求-响应”或“通知”。一个典型的工作流如下初始化Initialize连接建立后Client 首先发送initialize请求携带自己的元数据如支持的能力。Server 回复initialize_result并附上自己提供的资源、工具、提示词模板的列表。这是“能力协商”阶段。列出清单ListingClient 可以发送tools/list、resources/list、prompts/list请求获取详细的能力描述。执行操作Execution当 AI 模型需要读取数据时发送resources/read请求。当需要执行操作时发送tools/call请求。当需要提示词时发送prompts/get请求。通知NotificationServer 可以主动向 Client 发送通知。例如当某个资源的内容发生变化时如日志文件更新了Server 可以发送resources/updated通知Client 可以据此决定是否重新读取。这是一个非常重要的特性使得 MCP 能支持一定程度的实时数据流。为什么选择 JSON-RPC因为它简单、通用、语言无关。几乎任何编程语言都有成熟的 JSON-RPC 库这使得实现 MCP 的 Client 或 Server 变得相对容易。消息是纯文本的 JSON也便于调试和日志记录。3.2 安全与权限尚未标准化但至关重要目前MCP 协议规范本身并没有强制规定身份验证和授权机制。这是一个“将复杂性下放”的设计选择同时也意味着安全需要由实现者来保障。这在实际部署中是一个必须严肃对待的问题。常见的几种安全实践模式传输层安全如果使用 SSE over HTTP那么可以利用 HTTPS、HTTP 基本认证、API 密钥等现有的 Web 安全机制。Server 可以在初始化阶段验证 Client 的身份。进程隔离与信任边界在 stdio 模式下MCP Server 通常作为一个子进程被 MCP Client如 Claude Desktop启动。此时安全模型依赖于操作系统进程间的信任关系。谁有权启动这个 Server 进程就成了关键。这种方式适合本地、可信环境下的工具扩展。Server 内部实现权限控制这是最核心的一层。即使连接建立了MCP Server 在实现每一个工具如execute_sql和资源如read_database时内部也应该进行权限检查。例如一个 Server 可以映射到数据库的只读用户那么即使 Agent 请求DROP TABLE底层的数据库用户也没有权限执行。输入验证与净化MCP Server 必须对所有来自 Client 的输入特别是工具调用的参数进行严格的验证和净化防止注入攻击。例如对于 SQL 执行工具更安全的做法是只允许执行预定义的查询语句或存储过程而不是接受任意的 SQL 字符串。注意在评估或使用一个 MCP Server 时务必审查其安全设计。一个暴露了shell_exec工具且没有权限控制的 Server 是极其危险的。对于生产环境建议将 MCP Server 部署在独立的、网络隔离的容器中并通过严格的网络策略和身份认证来访问。4. 实战从零构建一个简单的 MCP Server理论说得再多不如动手写一个。我们以构建一个“系统信息查询” MCP Server 为例它提供一个资源只读的实时系统负载和一个工具获取指定目录的文件列表。我们将使用TypeScript和官方modelcontextprotocol/sdk来实现。4.1 环境准备与项目初始化首先确保你安装了 Node.js版本 18和 npm。然后创建一个新目录并初始化项目mkdir my-system-mcp-server cd my-system-mcp-server npm init -y npm install modelcontextprotocol/sdk npm install -D typescript ts-node types/node npx tsc --init在package.json中添加一个启动脚本{ scripts: { start: ts-node src/index.ts } }4.2 核心 Server 实现创建src/index.ts文件开始编写 Server 逻辑。import { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { CallToolRequestSchema, ListResourcesRequestSchema, ListToolsRequestSchema, ReadResourceRequestSchema, } from modelcontextprotocol/sdk/types.js; import os from os; import fs from fs/promises; import path from path; // 1. 创建 Server 实例 const server new Server( { name: my-system-mcp-server, version: 0.1.0, }, { capabilities: { // 声明我们支持哪些能力 resources: {}, // 支持资源 tools: {}, // 支持工具 // prompts: {}, // 本例暂不实现提示词模板 }, } ); // 2. 定义并注册“系统负载”资源 const SYSTEM_LOAD_URI system://loadavg; server.setRequestHandler(ListResourcesRequestSchema, async () { return { resources: [ { uri: SYSTEM_LOAD_URI, mimeType: application/json, name: 系统平均负载, description: 获取过去1、5、15分钟的系统平均负载。, }, ], }; }); server.setRequestHandler(ReadResourceRequestSchema, async (request) { if (request.params.uri SYSTEM_LOAD_URI) { const loadavg os.loadavg(); // [1min, 5min, 15min] return { contents: [ { uri: SYSTEM_LOAD_URI, mimeType: application/json, // 将负载数据以 JSON 字符串形式返回 text: JSON.stringify({ load_1min: loadavg[0], load_5min: loadavg[1], load_15min: loadavg[2], cores: os.cpus().length, timestamp: new Date().toISOString(), }, null, 2), }, ], }; } throw new Error(Resource not found: ${request.params.uri}); }); // 3. 定义并注册“列出文件”工具 server.setRequestHandler(ListToolsRequestSchema, async () { return { tools: [ { name: list_directory, description: 列出指定目录下的文件和文件夹。, inputSchema: { type: object, properties: { directoryPath: { type: string, description: 要列出的目录路径。默认为当前工作目录。, }, }, required: [], // directoryPath 不是必需的 }, }, ], }; }); server.setRequestHandler(CallToolRequestSchema, async (request) { if (request.params.name list_directory) { const args request.params.arguments as { directoryPath?: string }; const targetDir args.directoryPath || process.cwd(); // 简单的安全校验防止目录遍历攻击非常基础版 const resolvedPath path.resolve(targetDir); if (!resolvedPath.startsWith(process.cwd())) { throw new Error(出于安全考虑只能列出当前工作目录及其子目录。); } try { const items await fs.readdir(resolvedPath, { withFileTypes: true }); const list items.map((item) ({ name: item.name, type: item.isDirectory() ? directory : file, isDirectory: item.isDirectory(), isFile: item.isFile(), })); return { content: [ { type: text, text: 目录 ${targetDir} 下的内容\n${JSON.stringify(list, null, 2)}, }, ], }; } catch (error: any) { return { content: [ { type: text, text: 错误无法读取目录 ${targetDir}。原因${error.message}, }, ], isError: true, }; } } throw new Error(Tool not found: ${request.params.name}); }); // 4. 启动 Server使用 stdio 传输 async function main() { const transport new StdioServerTransport(); await server.connect(transport); console.error(MCP System Info Server running on stdio...); } main().catch((error) { console.error(Server error:, error); process.exit(1); });4.3 运行与测试首先编译并运行你的 Servernpm start此时 Server 会挂起等待通过 stdin/stdout 接收来自 Client 的 JSON-RPC 消息。要测试它我们需要一个 MCP Client。最方便的是使用Claude Desktop如果已经配置了 MCP 支持或者使用一个简单的测试脚本。这里我们用官方 SDK 自带的简单测试方法创建一个test_client.tsimport { Client } from modelcontextprotocol/sdk/client/index.js; import { StdioClientTransport } from modelcontextprotocol/sdk/client/stdio.js; import { spawn } from child_process; async function test() { // 启动 Server 进程 const serverProcess spawn(ts-node, [src/index.ts], { stdio: [pipe, pipe, inherit] // 将 stderr 继承到控制台以便调试 }); // 创建 Transport 和 Client const transport new StdioClientTransport({ command: echo, // 占位符实际进程已启动 args: [], process: serverProcess // 直接传入已启动的进程 }); const client new Client( { name: test-client, version: 0.1.0, }, { capabilities: {}, } ); await client.connect(transport); // 测试1列出资源 console.log( Listing Resources ); const resources await client.listResources(); console.log(JSON.stringify(resources, null, 2)); // 测试2读取系统负载资源 console.log(\n Reading System Load Resource ); const loadData await client.readResource({ uri: system://loadavg }); console.log(loadData.contents[0].text); // 测试3列出工具 console.log(\n Listing Tools ); const tools await client.listTools(); console.log(JSON.stringify(tools, null, 2)); // 测试4调用 list_directory 工具 console.log(\n Calling list_directory Tool ); const result await client.callTool({ name: list_directory, arguments: { directoryPath: ./ }, }); console.log(result.content[0].text); await client.close(); serverProcess.kill(); } test().catch(console.error);运行测试脚本npx ts-node test_client.ts。你应该能看到 Server 返回的系统负载信息和当前目录的文件列表。4.4 集成到 Claude Desktop要让这个 Server 真正被 AI 使用可以将其集成到 Claude Desktop 中。这通常需要在 Claude Desktop 的配置文件中添加 MCP Server 的设置。找到 Claude Desktop 的配置目录例如在 macOS 上是~/Library/Application Support/Claude/claude_desktop_config.json添加如下配置{ mcpServers: { my-system-server: { command: node, args: [/ABSOLUTE/PATH/TO/YOUR/PROJECT/build/index.js], // 指向你编译后的 JS 文件 env: {} } } }重启 Claude Desktop 后Claude 就能“看到”并使用你编写的list_directory工具和system://loadavg资源了。你可以直接问它“当前系统负载高吗”或者“帮我列出项目根目录下的文件。”实操心得错误处理是关键在callTool和readResource的处理函数中务必进行充分的错误捕获和用户友好的错误信息返回。将底层错误如文件不存在、权限不足转化为 AI 模型能理解的文本。描述要清晰工具和资源的description字段至关重要。AI 模型依赖这些描述来决定何时使用它们。描述应简洁、准确地说明功能、输入和输出。安全是底线我们这个示例中的路径安全检查非常基础。在生产环境中你需要更严格的策略比如配置允许访问的目录白名单、验证用户身份等。永远不要相信来自 Client 的未经净化的输入。5. MCP 生态现状、挑战与未来展望MCP 自推出以来发展迅速但其生态仍处于早期阶段机遇与挑战并存。5.1 当前生态概览目前MCP 生态主要围绕以下几个方向展开官方与核心 ServerAnthropic 官方维护了一些基础 Server如filesystem文件系统、postgres数据库、brave-search搜索等展示了协议的最佳实践。第三方工具集成社区已经创建了大量 Server将流行的开发工具、云服务、数据源接入 MCP。例如GitHub / GitLab管理仓库、查看 Issue、提交 PR。Jira / Linear项目管理与任务查询。Datadog / Sentry查看监控指标和错误日志。AWS / GCP / Azure云资源查询与管理需谨慎处理权限。Notion / Slack读写知识库和发送消息。Client 端支持Claude Desktop目前对 MCP 支持最完善、体验最好的客户端是许多用户接触 MCP 的入口。Cursor IDE / Windsurf这些 AI 原生编辑器开始集成 MCP允许 AI 助手在编码时直接调用外部工具。自定义 Agent 框架开发者可以在自己的 AI Agent 应用中嵌入 MCP Client SDK使其具备动态扩展工具的能力。5.2 面临的主要挑战尽管前景广阔MCP 在普及过程中也面临一些现实挑战安全与权限模型的缺失如前所述协议层缺乏强制性的安全标准。这导致每个 Server 需要自行实现一套权限体系增加了开发复杂性和安全审计的难度。企业级应用尤其需要清晰的租户隔离、角色权限控制和审计日志。工具发现的“冷启动”问题一个 Agent 如何知道该连接哪个 MCP Server目前多靠手动配置。未来可能需要一个“Server 注册中心”或“能力发现服务”让 Agent 能动态发现并请求接入所需的工具。复杂交互与状态管理MCP 目前的工具调用是“单次请求-响应”模式。对于需要多轮交互的复杂任务例如引导用户完成一个多步骤的配置流程支持还不够好。这需要扩展协议或由上层 Orchestrator 来管理会话状态。性能与稳定性MCP Server 通常作为独立进程运行频繁的进程间通信IPC可能带来延迟。对于高并发或低延迟要求的场景需要优化传输层或采用更高效的通信方式。标准化与碎片化风险虽然 MCP 旨在统一但如果各大厂商如 OpenAI、Google都推出自己的“类似但不同”的 Agent 工具协议生态可能会碎片化。MCP 需要更广泛的行业采纳来避免这一问题。5.3 未来可能的演进方向从我个人的观察和项目实践来看MCP 及其代表的方向可能会朝以下几个方面演进协议分层与专业化可能会出现更细分的协议层。例如基础 MCP 定义核心通信而针对“数据库操作”、“云资源控制”、“企业内部系统”等特定领域会衍生出更精确、包含领域语义的“Profile”或“扩展”。与 Agent 框架深度集成像 LangChain、LlamaIndex、AutoGen 这样的 Agent 框架可能会将 MCP Client 作为一级公民集成。开发者可以直接在框架中配置 MCP Server 地址框架自动处理工具调用、资源读取和提示词组合。“可观测性”与“调试”工具随着 MCP 网络变得复杂对 MCP 通信进行监控、调试和记录的需求会激增。未来可能会出现专门的 MCP 流量分析工具帮助开发者理解 Agent 的决策链条和工具使用情况。边缘与本地优先出于数据隐私和延迟考虑很多 MCP Server 会部署在本地或边缘网络。MCP 的轻量级和进程隔离特性非常适合这种场景推动 AI 能力向终端下沉。最后再分享一个小技巧在规划你自己的 MCP Server 时不妨从“资源”入手而不是“工具”。因为提供只读的“资源”通常更安全也更容易让 AI 模型理解。先让 Agent 能“看到”你的数据世界再逐步、谨慎地开放“执行”能力。例如先做一个能暴露项目代码结构、API 文档、日志摘要的 Server观察 AI 如何利用这些信息再考虑是否开放创建工单、执行部署等写操作工具。这种渐进式的开放能让你在享受 MCP 便利的同时更好地控制风险。