MCP协议：AI Agent的TCP/IP时刻，从单机智能到网络智能

1. 从“单机智能”到“网络智能”：为什么我们需要MCP？

最近在折腾AI Agent开发的朋友，可能都听过一个词：MCP。它被一些人称为“AI Agent的TCP/IP时刻”，这个类比听起来很宏大，甚至有点唬人。我第一次听到时，心里也犯嘀咕：又一个新概念炒作？但当我真正深入去研究、去用它连接不同的工具和模型时，我才意识到，这个比喻可能并不夸张，它确实在尝试解决一个底层且关键的问题——AI Agent之间的“巴别塔困境”。

想象一下早期的计算机网络。每台计算机都是一个信息孤岛，有自己的文件系统、自己的应用程序，但它们之间无法直接对话。你要从A机传个文件到B机，可能需要用软盘拷来拷去。TCP/IP协议的出现，定义了一套通用的“语言”和“邮递规则”，让不同硬件、不同操作系统的机器能够相互识别、寻址、可靠地传输数据包。从此，单机变成了网络，信息的价值呈指数级放大。

现在的AI Agent生态，就有点像那个“前TCP/IP时代”。我们有了强大的大语言模型（LLM），有了各种专业工具（比如数据库查询、代码执行、文件操作、调用第三方API），也有了让LLM使用这些工具的框架（如LangChain、LlamaIndex）。但问题在于，每个工具、每个数据源、每个外部服务，都需要开发者为其编写特定的“适配器”或“插件”。这个适配器告诉LLM：“嘿，你想查数据库吗？你得用这样的格式跟我说话。” 另一个适配器又说：“不，你想读文件的话，得按我的规矩来。”

这就导致了一个非常头疼的局面：Agent的能力与其集成的工具强绑定。你为一个搜索Agent写的工具接口，几乎无法直接复用到另一个数据分析Agent上。更麻烦的是，当工具本身更新，或者你想换一个功能类似但实现不同的工具时，往往需要重写大量的胶水代码。Agent的开发、测试、部署和维护成本居高不下，且难以形成可复用的生态。

MCP（Model Context Protocol）协议的目标，就是成为AI Agent世界的“TCP/IP”。它试图定义一套标准化的通信协议，让任何AI模型（Server）能够以一种统一的方式，去发现、理解并调用任何外部工具、数据源或服务（这些统称为“资源”）。简单说，MCP希望达成的效果是：一个Agent开发者，不需要关心他最终会连接哪些具体工具；而一个工具开发者，也不需要关心他的工具会被哪个具体的Agent使用。双方只要都遵循MCP协议，就能即插即用。

这不仅仅是技术上的便利，更是生态层面的质变。它意味着工具可以独立于AI框架发展，AI Agent可以像组装乐高一样灵活搭配能力，整个领域的创新和协作效率将会被极大提升。这就是“TCP/IP时刻”的含义——从封闭、割裂的“单机智能”，走向开放、互联的“网络智能”。

2. MCP协议核心架构：Server, Client与Transport

要理解MCP，我们必须先拆解它的核心架构。它采用了经典的客户端-服务器（Client-Server）模型，但这个模型里的角色和我们通常理解的有点不同。

2.1 核心角色定义

MCP Server（服务器）： 这是协议的“能力提供方”。你可以把它想象成一个“工具管家”或“数据管家”。它的核心职责是向外界宣告：“我这里有什么工具（Tools）可以用，有什么数据（Resources）可以读。” 一个MCP Server可以管理多个工具和资源。例如：

• 一个“文件系统Server”可以提供read_file、write_file、list_directory等工具。
• 一个“数据库Server”可以提供execute_query工具。
• 一个“天气API Server”可以提供get_weather工具和current_weather这个动态资源。
• 甚至一个“计算器Server”可以提供calculate工具。

MCP Client（客户端）： 这是协议的“能力消费方”。通常，这就是我们的AI应用或AI Agent框架（例如，一个基于LangChain构建的Agent）。Client的核心职责是连接到Server，发现Server提供了哪些工具和资源，然后在需要的时候，按照协议格式向Server发起调用请求，并处理返回的结果。Client是“大脑”，它决定什么时候、为什么、以及如何使用这些工具。

Transport（传输层）： 这是Client和Server之间通信的“高速公路”。MCP协议本身不限定具体的传输方式，它设计为与传输层解耦。目前主流支持两种方式：

1. stdio（标准输入输出）： 最简单的方式。Client作为一个进程，启动Server作为子进程，两者通过管道（stdin/stdout）进行JSON-RPC消息的交换。这种方式部署简单，适合本地集成。
2. SSE（Server-Sent Events）： 基于HTTP的传输方式。Server运行一个HTTP服务，Client通过HTTP连接到它，并使用SSE来接收Server主动推送的消息（如资源变更通知）。这种方式更适合远程、网络化的部署场景。

这个架构的精妙之处在于关注点分离。Server只关心如何实现工具的具体功能（比如怎么查数据库），并按照MCP格式暴露接口。Client只关心如何根据任务需求，选择并调用合适的工具。两者通过标准的Transport和协议消息进行对话，彼此无需知晓对方的具体实现。

2.2 通信基石：JSON-RPC

MCP协议的所有消息交互都建立在JSON-RPC 2.0规范之上。这是一个轻量级的远程过程调用（RPC）协议，使用JSON格式来编码请求和响应。选择JSON-RPC是因为它简单、通用、语言无关，几乎所有的编程语言都有成熟的库支持。

一个典型的MCP交互流程是这样的：

1. 初始化（Initialize）： Client启动，通过Transport连接到Server，发送一个initialize请求。这个请求中包含了Client的元信息（比如支持的能力）。Server回复initialize结果，并附上自己的元信息。
2. 工具与资源列表（Listing）： 紧接着，Client会发送tools/list和resources/list请求，来获取Server提供的所有工具和资源的清单。Server返回一个结构化的列表。
3. 调用工具（Tool Call）： 当Agent（在Client中）决定使用某个工具时，Client会向Server发送一个tools/call请求，其中包含了工具名和调用参数（arguments）。Server执行工具逻辑，然后返回一个tools/call结果，里面包含了执行产出（文本、图片、数据等）或错误信息。
4. 读取资源（Resource Read）： 如果Agent需要获取某个资源（比如一个配置文件的内容），Client会发送resources/read请求。Server返回资源的内容。

所有的请求和响应，都是遵循JSON-RPC格式的JSON对象。例如，一个工具调用请求大概长这样：

{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "search_web", "arguments": { "query": "MCP protocol latest version", "limit": 5 } } }

而Server的响应则像这样：

{ "jsonrpc": "2.0", "id": 1, "result": { "content": [ { "type": "text", "text": "1. Model Context Protocol (MCP) v1.0 was announced by Anthropic in...\n2. The protocol aims to standardize..." } ] } }

这种基于标准JSON-RPC的通信，使得MCP Client和Server的实现变得非常清晰和规范，调试起来也相对容易，你可以直接查看流动的JSON消息来定位问题。

3. 协议核心能力拆解：Tools, Resources 与 Prompts

MCP协议定义了三种主要的能力类型，这是Server能够提供给Client的“货物”。理解这三者的区别和用途，是灵活运用MCP的关键。

3.1 Tools（工具）：让AI“动手操作”

Tools是MCP中最核心的概念，它代表了一个可执行的操作。当AI需要主动去做一件事时，比如搜索网络、运行代码、写入文件，它就会调用一个Tool。

每个Tool都有明确的定义：

• name（名称）： 唯一标识符，如calculate、send_email。
• description（描述）： 用自然语言描述这个工具是做什么的。这部分描述至关重要，因为AI（LLM）正是通过阅读这段描述来理解何时以及如何使用这个工具。描述应该清晰、无歧义。
• inputSchema（输入模式）： 严格定义调用这个工具时需要提供的参数。它遵循JSON Schema规范，规定了每个参数的名字、类型、是否必填、描述以及可能的枚举值。这为AI提供了结构化的指导，也确保了调用的安全性。

例如，一个“发送邮件”的Tool定义可能包含recipient（字符串，必填）、subject（字符串，必填）、body（字符串，必填）等参数。

当Client调用一个Tool后，Server会执行相应的逻辑，并返回一个结构化的结果。结果通常是一个Content数组，里面可以包含文本（type: "text"）、图片（type: "image"，以base64或URL形式）、或其他MCP定义的数据类型。这种统一的返回格式，使得Client（AI）能够以一致的方式解析和处理任何Tool的执行结果。

3.2 Resources（资源）：让AI“获取信息”

如果说Tools是“动词”，那么Resources就是“名词”。它代表AI可以读取的静态或动态信息源。当AI需要了解某些信息作为上下文时，比如读取一个项目文件、获取当前的股票价格、查看系统状态，它就会读取一个Resource。

每个Resource也有其定义：

• uri（统一资源标识符）： 类似URL，用于唯一标识一个资源，如file:///project/README.md或weather://current/newyork。
• mimeType（媒体类型）： 指明资源的内容格式，如text/plain、application/json、image/png。这帮助AI正确解析内容。
• description（描述）： 同样，用自然语言描述这个资源是什么。

Resources的一个强大特性是支持推送通知（Notifications）。Server可以在资源内容发生变化时（比如一个日志文件被更新了），主动通知Client：“嘿，你之前读过的那个资源，它现在变了。” Client可以选择重新读取该资源，以获取最新的信息。这对于构建实时感知环境的Agent（如监控告警Agent）非常有用。

Tools和Resources的使用场景区分： 简单来说，当AI需要改变外部状态（做一件事）时，用Tool；当AI需要获取外部状态（了解一件事）时，用Resource。例如，写文件是Tool，读文件是Resource；执行数据库插入是Tool，查询数据库是Resource。

3.3 Prompts（提示词模板）：让AI“专业对话”

这是MCP中一个非常巧妙的设计。Prompts不是直接的操作或数据，而是预定义的、参数化的对话模板或指令集。你可以把它理解为给AI的“标准作业程序”（SOP）或“对话脚手架”。

一个Prompt定义包括：

• name（名称）： 如code_review、brainstorming。
• description（描述）： 说明这个提示词的用途。
• arguments（参数）： 和Tool类似，定义模板所需的输入参数，如code_snippet（代码片段）、topic（讨论主题）。

当Client请求一个Prompt时，Server并不是返回一个执行结果，而是返回一个或多个Message对象（通常是role: "user"或role: "assistant"的消息）。这些消息构成了一个对话的“开头”或“框架”。然后，Client可以将这个预填充的对话上下文直接交给LLM，让LLM在此基础上继续对话。

这有什么用呢？它允许Server的开发者将领域专家的知识封装成Prompt模板。例如，一个“代码评审Server”可以提供code_review这个Prompt。当Client请求它并传入一段代码时，Server返回的Message可能是：“你是一个资深Python代码评审专家，请严格评审以下代码，重点关注性能、安全性和可读性：[用户代码]”。这样，任何连接到这个Server的AI Agent，都能立刻具备专业的代码评审能力，而不需要每个Agent开发者自己去编写复杂的评审提示词。

4. 实战：从零构建一个MCP Server

理解了理论，我们动手实现一个最简单的MCP Server，这比看十遍文档都管用。我们将使用官方推荐的TypeScript SDK来构建，因为它类型安全，文档完善。

4.1 环境准备与项目初始化

首先，确保你的环境有Node.js（建议18+版本）和npm。然后创建一个新目录并初始化项目：

mkdir my-first-mcp-server cd my-first-mcp-server npm init -y

接下来，安装MCP的核心依赖。我们需要@modelcontextprotocol/sdk，它提供了构建Server和Client所需的所有类型和工具。

npm install @modelcontextprotocol/sdk

同时，由于我们用TypeScript开发，安装TypeScript和相关的类型定义：

npm install --save-dev typescript @types/node npx tsc --init

在生成的tsconfig.json中，确保target是ES2022或更高，module是commonjs或NodeNext，并设置outDir为./dist。

4.2 实现一个“系统信息查询”Server

我们的目标是创建一个Server，提供两个能力：

1. 一个Tool：get_system_info，返回当前系统的内存使用率和CPU负载。
2. 一个Resource：file:///server/status，以JSON格式返回服务器的运行状态（如启动时间）。

首先，创建入口文件src/index.ts：

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"; // 1. 创建Server实例 const server = new Server( { name: "system-info-server", version: "0.1.0", }, { capabilities: { // 声明我们支持哪些功能 tools: {}, resources: {}, }, } ); // 2. 定义并注册 Tool：get_system_info server.setRequestHandler(ListToolsRequestSchema, async () => { return { tools: [ { name: "get_system_info", description: "获取当前系统的内存使用率和CPU负载信息。", inputSchema: { type: "object", properties: {}, // 这个工具不需要输入参数 required: [], }, }, ], }; }); server.setRequestHandler(CallToolRequestSchema, async (request) => { if (request.params.name !== "get_system_info") { throw new Error(`Unknown tool: ${request.params.name}`); } // 实现工具逻辑 const totalMem = os.totalmem(); const freeMem = os.freemem(); const usedMem = totalMem - freeMem; const memoryUsagePercent = ((usedMem / totalMem) * 100).toFixed(2); const cpus = os.cpus(); const avgCpuLoad = cpus.reduce((acc, cpu) => acc + cpu.times.user + cpu.times.nice + cpu.times.sys, 0) / cpus.length; return { content: [ { type: "text", text: `系统状态报告： - 内存使用率: ${memoryUsagePercent}% - 总内存: ${(totalMem / 1024 / 1024 / 1024).toFixed(2)} GB - 空闲内存: ${(freeMem / 1024 / 1024 / 1024).toFixed(2)} GB - CPU平均负载（用户+系统时间）: ${avgCpuLoad.toFixed(0)} ms`, }, ], }; }); // 3. 定义并注册 Resource：file:///server/status const serverStartTime = new Date().toISOString(); server.setRequestHandler(ListResourcesRequestSchema, async () => { return { resources: [ { uri: "file:///server/status", mimeType: "application/json", name: "Server Status", description: "本MCP服务器的运行状态信息。", }, ], }; }); server.setRequestHandler(ReadResourceRequestSchema, async (request) => { if (request.params.uri !== "file:///server/status") { throw new Error(`Unknown resource: ${request.params.uri}`); } const statusInfo = { serverName: "system-info-server", version: "0.1.0", startTime: serverStartTime, uptime: process.uptime(), nodeVersion: process.version, }; return { contents: [ { uri: request.params.uri, mimeType: "application/json", text: JSON.stringify(statusInfo, null, 2), // 美化输出的JSON }, ], }; }); // 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 编译、运行与测试

编写完成后，我们需要编译TypeScript代码并运行。

首先，在package.json中添加一个启动脚本：

{ "scripts": { "build": "tsc", "start": "node dist/index.js" } }

然后编译并运行：

npm run build npm start

此时，Server会启动并等待通过stdio接收连接。你会看到console.error输出的提示信息（MCP消息使用stdio，所以日志用console.error输出到stderr是常见做法）。

如何测试？我们可以写一个最简单的MCP Client来测试，但更快捷的方式是使用MCP Inspector。这是一个官方提供的调试工具，可以直观地查看Server提供的工具和资源，并手动调用它们。

首先，全局安装MCP Inspector：

npm install -g @modelcontextprotocol/inspector

然后，在另一个终端，使用Inspector连接我们的Server：

mcp-inspector node dist/index.js

Inspector会启动一个本地网页（通常是http://localhost:5173），打开后你就能看到我们的Serversystem-info-server，并可以展开查看get_system_info工具和file:///server/status资源。点击工具旁的“调用”按钮，就能看到返回的系统信息；点击资源旁的“读取”按钮，就能看到服务器状态JSON。这证明了我们的Server工作正常。

5. 在真实AI Agent中集成MCP：以Cursor为例

构建出Server只是第一步，真正的价值在于让AI Agent使用它。目前，已经有一些前沿的AI开发工具开始集成MCP。Cursor和Claude Desktop是其中的典型代表。这里我们以开发者常用的Cursor为例，看看如何让它使用我们刚写的Server。

Cursor（特别是其Composer模式）内置了MCP Client能力。它允许你通过配置文件来声明需要连接的MCP Server。这样，当你与Cursor的AI对话时，AI就能自动发现并使用这些Server提供的工具。

配置通常位于~/.cursor/mcp.json（macOS/Linux）或%USERPROFILE%\.cursor\mcp.json（Windows）。这个文件是一个JSON数组，每个元素配置一个MCP Server。

要让Cursor使用我们本地开发的system-info-server，我们需要创建一个启动脚本，并配置Cursor去调用它。

1. 创建启动脚本： 在项目根目录创建一个run_server.sh（Linux/macOS）或run_server.bat（Windows）文件。

   • Linux/macOS (run_server.sh):

     #!/bin/bash node /绝对路径/to/your/my-first-mcp-server/dist/index.js

     记得给脚本执行权限：chmod +x run_server.sh
   • Windows (run_server.bat):

     @echo off node C:\绝对路径\to\your\my-first-mcp-server\dist\index.js

2. 配置Cursor的mcp.json： 编辑（或创建）~/.cursor/mcp.json文件。

   [ { "mcpServers": { "system-info": { "command": "/绝对路径/to/your/my-first-mcp-server/run_server.sh", // 如果是Windows，用： // "command": "cmd.exe", // "args": ["/c", "C:\\绝对路径\\to\\your\\my-first-mcp-server\\run_server.bat"] "args": [] } } } ]

   注意： 这里有一个关键细节。直接配置command为node和脚本路径有时可能因为环境变量问题导致失败。更稳健的做法是像上面一样，通过shell脚本或cmd.exe来间接启动。确保路径是绝对路径，并且Node.js在对应的shell环境中可用。

3. 重启Cursor并验证： 完全关闭Cursor并重新打开。打开一个项目或对话，尝试问AI：“你能获取一下当前系统的信息吗？” 或者 “请读取一下服务器的状态。” 如果配置成功，Cursor的AI（通常是Claude模型）会识别到可用的get_system_info工具，并主动调用它，然后将结果返回给你。

这个过程看似简单，但意义重大。这意味着，你无需修改Cursor的一行代码，就为它扩展了获取系统信息的新能力。未来，你可以将任何功能（数据库、搜索引擎、内部API）封装成MCP Server，并以同样的方式“插”进Cursor或其他支持MCP的AI应用中。这就是协议化、标准化带来的威力。

6. 深入协议细节：错误处理、生命周期与进阶特性

要让一个MCP Server健壮、可用，仅仅实现基本功能是不够的。我们还需要深入协议的一些细节。

6.1 健壮的错误处理

在CallToolRequestSchema和ReadResourceRequestSchema的处理函数中，我们进行了简单的错误判断。但实际的错误处理需要更细致。

• 输入验证： 即使有inputSchema，Client也可能发送格式错误或类型不匹配的参数。Server端应该对request.params.arguments进行二次验证。
• 工具执行错误： 工具逻辑本身可能失败（如网络超时、文件不存在）。这些错误应该被捕获，并通过JSON-RPC的error对象返回，而不是让进程崩溃。错误信息应清晰，便于AI或开发者理解。

  server.setRequestHandler(CallToolRequestSchema, async (request) => { try { // ... 工具逻辑 if (somethingWentWrong) { throw new Error("Failed to connect to the external API."); } return { content: [...] }; } catch (error) { // 返回结构化的错误信息 return { content: [ { type: "text", text: `Tool execution failed: ${error.message}`, }, ], // 或者使用JSON-RPC error（取决于Server SDK的实现） // 通常SDK会帮你处理，你只需要抛出异常即可 }; } });

• 资源不存在： 对于ReadResourceRequestSchema，请求的URI可能无效。应该返回明确的错误，而不是崩溃。

6.2 Server的生命周期管理

我们的示例Server启动后就一直运行。但在生产环境中，需要考虑更多：

• 优雅关闭： Server应该监听SIGINT（Ctrl+C）等信号，在关闭前清理资源（如关闭数据库连接），并通知Client连接即将中断。
• 心跳与健康检查： 对于SSE等长连接传输，Server可能需要实现ping/pong机制来保持连接活跃，并允许Client进行健康检查。
• 资源清理： 当Client断开连接时，Server是否应该释放为该Client分配的资源？协议定义了notifications/initialized和notifications/exit等通知，可用于管理会话生命周期。

6.3 进阶特性探索

• 资源变更通知（Resource Notifications）： 这是MCP的一个亮点。Server可以在资源内容变化时，主动向Client发送notifications/resources/updated通知。要实现这个，Server需要维护一个订阅列表，并在数据变化时推送。这对于构建实时数据看板、日志监控等场景的Agent至关重要。
• 提示词模板的变体（Prompt Variations）： 一个Prompt可以定义多个variants，针对同一任务提供不同风格或详细程度的模板。Client可以根据场景选择。
• 工具调用的渐进式结果（Progress Updates）： 对于执行时间较长的工具（如训练模型、处理大文件），Server可以分多次发送notifications/tools/call_update通知，向Client报告进度，提升交互体验。
• 认证与安全： 对于需要访问敏感数据或执行危险操作的Server，必须实现认证。MCP协议允许在initialize握手阶段交换认证信息。Server可以拒绝未授权的连接请求。在实现时，务必不要在工具中硬编码密钥，而应通过环境变量或安全的配置管理系统传入。

7. 生态现状、挑战与最佳实践

MCP协议由Anthropic主导推出，目前还处于早期但快速发展的阶段。它的出现，正在悄然改变AI Agent的开发范式。

7.1 当前生态概览

• 官方与社区Server： 已经涌现出一批实用的MCP Server。例如：
  • 文件系统： 提供基本的文件读写、目录列表。
  • Git： 集成Git操作，让AI可以查看提交历史、差异，甚至创建提交。
  • 网络搜索： 连接搜索引擎（如DuckDuckGo、Serper）。
  • 数据库： 连接PostgreSQL、MySQL等，执行安全查询。
  • 项目管理工具： 连接Jira、Linear、GitHub Issues等。
• 支持的Client：Claude Desktop是首个原生深度集成MCP的消费级应用。Cursor作为AI驱动的IDE，也迅速跟进，成为开发者体验MCP的主要窗口。此外，LangChain、LlamaIndex等主流框架也正在增加对MCP的原生支持，未来任何基于它们构建的Agent都能轻松接入MCP生态。
• 开发工具： 除了前面提到的MCP Inspector，还有MCP CLI等工具，帮助开发者快速创建、测试和调试Server。

7.2 开发中的常见“坑”与解决方案

1. 传输层配置错误： 这是新手最常见的问题。stdio模式下，Server必须从stdin读取，向stdout写入，且不能向stdout打印任何调试日志，否则会污染协议消息。所有日志必须使用console.error输出到stderr。在SSE模式下，则要正确处理HTTP请求和长连接。
2. 工具描述（description）质量差： AI完全依赖描述来理解工具。模糊的描述（如“处理数据”）会导致AI误用或不用。好的描述应清晰说明功能、输入参数的含义、以及典型使用场景。例如：“根据城市名查询未来三天的天气预报，返回温度、天气状况和降水概率。”
3. 输入模式（inputSchema）设计不合理： 过于宽松的Schema（如所有参数都是可选的string）会让AI困惑。应该尽可能严格：使用enum限定可选值，用description说明每个参数，标记required字段。这既是给AI的说明书，也是一层安全校验。
4. 忽略错误处理和边界情况： 工具可能被传入意外值，外部服务可能宕机。Server必须健壮，返回友好的错误信息，而不是崩溃。这关系到整个Agent系统的稳定性。
5. 性能问题： 如果工具执行慢（如调用慢速API），会阻塞整个AI响应。考虑实现异步操作或进度通知。对于资源读取，如果资源很大，可以考虑分页或流式返回。

7.3 设计MCP Server的最佳实践

• 单一职责： 一个Server最好只负责一个紧密相关的领域（如“数据库操作”、“Git操作”）。这符合Unix哲学，也便于维护和复用。
• 无状态设计： 尽可能将Server设计为无状态的。会话特定的信息应该由Client在每次请求中提供。这使Server更容易扩展和部署。
• 安全性至上：
  • 权限最小化： Server只暴露必要的最少工具和资源。一个文件系统Server可能只暴露特定目录的读取权限，而非整个根目录。
  • 输入消毒： 对所有来自Client的输入进行严格的验证和转义，特别是当参数用于拼接命令或SQL查询时，防止注入攻击。
  • 敏感信息隔离： API密钥、数据库密码等绝不应硬编码在代码中，应通过环境变量或安全的Secret管理服务传入。
• 提供丰富的元数据： 除了基本的name和description，在initialize响应和工具/资源列表中提供更多信息，如作者、版本、文档链接，这有助于Client和开发者更好地理解和使用你的Server。
• 编写完备的文档： 为你的Server编写清晰的README，说明其功能、配置方法、工具/资源的详细定义和使用示例。这对于社区共享至关重要。

MCP协议正在为AI Agent的互操作性打下坚实的地基。它抽象了连接的复杂性，让开发者能专注于创造有价值的能力。虽然生态还在萌芽期，标准也在演进，但提前理解并掌握它，无疑会让你在构建下一代AI应用时占据先机。从今天开始，尝试将你手头的某个脚本或服务包装成一个MCP Server，体验一下这种“即插即用”的智能扩展能力，你会发现，AI Agent的开发，真的可以像搭积木一样简单而有趣。