『MCP』模型上下文协议核心概念

🏛️ 深入MCP的核心：理解架构与通信

要真正掌握MCP，我们必须先理解其优雅而强大的架构设计。它就像一个精心组织的团队，每个成员各司其职，共同协作，确保LLM能够与外部世界高效、安全地对话。

三个火枪手：Host, Client & Server 🧑‍🤝‍🧑

MCP的架构遵循经典的客户端-服务器模型，但有其独特的角色划分。我们可以用一个生动的“餐厅”比喻来理解这三个核心角色：

Host (宿主)：这是用户直接交互的AI应用程序，比如Cursor IDE、Claude桌面版或VS Code。Host是整个MCP生态的“协调者”和“容器”。在我们的比喻中，Host就是整个餐厅大楼，它为所有活动提供了场所和管理。
Client (客户端)：客户端存在于Host内部。它是一个专职的连接器，负责与一个特定的MCP服务器维持一个**一对一的、有状态的连接。一个Host内部可以同时运行多个客户端实例，每个实例都像一个专职的

服务员，只负责与一个特定的厨房（服务器）沟通，传递订单和菜品。
Server (服务器)：这是一个轻量级的、独立的程序，它通过MCP协议向外暴露特定的能力（如数据或功能）。服务器就是餐厅里专门的厨房，比如一个只做川菜，另一个只做甜点。它接收来自服务员（客户端）的订单，并按要求准备好“菜品”（数据或工具执行结果）。

这种架构设计非常巧妙：Host负责复杂的UI、用户管理和LLM编排；Server专注于提供单一、明确的功能；而Client则作为中间的桥梁，将两者解耦。

协议的神经系统：通信层 🧠

MCP的通信建立在两个关键层之上：消息格式层和传输层。

基础：JSON-RPC 2.0

所有MCP客户端和服务器之间的消息都必须遵循JSON-RPC 2.0规范。这是一种轻量级的远程过程调用（RPC）协议，使用JSON格式进行数据交换。选择它是因为其简单、易读且与语言无关的特性。

MCP的语言：三种核心消息类型

MCP利用JSON-RPC定义了三种核心的消息类型，它们构成了双方对话的基本单元：

Request (请求)：当一方（客户端或服务器）希望另一方执行某个操作时发送。它必须包含一个唯一的id（用于匹配响应）和一个method（要调用的方法名），以及可选的params（参数）。

请求示例 (客户端请求列出资源):

JSON
```
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {}
}
```
Response (响应)：这是对“请求”的回复。它必须包含与对应请求完全相同的id。响应分为两种：
- 成功响应：包含一个result字段，其内容是请求处理的结果。
- 错误响应：包含一个error字段，其中有code和message来描述错误详情。
成功响应示例:

JSON
```
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      { "uri": "file:///app/main.py", "name": "main.py" }
    ]
  }
}
```
Notification (通知)：这是一种“发后不理”的单向消息，用于发送事件或状态更新。它不包含id，因此接收方不能也绝不应该对其进行响应。

通知示例 (服务器通知客户端工具列表已变更):

JSON
```
{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}
```

消息的传递：传输层

传输层负责消息的物理传输。MCP目前主要支持两种传输机制：

Stdio (Standard Input/Output)：这是为本地服务器设计的。Host应用启动服务器作为一个子进程，然后通过其标准输入（stdin）和标准输出（stdout）管道来发送和接收JSON-RPC消息。这种方式非常适合本地开发工具，如文件系统访问或Git命令集成，因为它简单、高效且易于管理。
HTTP + SSE (Server-Sent Events)：这是为远程服务器设计的。它采用了一种非对称的通信模式：
- 客户端 -> 服务器：客户端通过标准的HTTP POST请求发送消息。
- 服务器 -> 客户端：服务器通过一个持久化的HTTP连接，使用Server-Sent Events (SSE)技术向客户端推送消息（如通知或对请求的响应）。
  
  这种方式完美兼容现有的Web基础设施，使得构建可扩展的、分布式的MCP服务成为可能。

特性	Stdio 传输 💻	HTTP SSE 传输 🌐
环境	本地 (同一台机器)	远程 (可通过网络访问)
部署方式	由Host作为子进程启动	部署为独立的Web服务器
认证方式	环境变量、手动配置	OAuth, API密钥 (标准Web安全)
最佳适用场景	本地开发工具、文件系统访问、单用户脚本	SaaS集成、多用户服务、共享工具
示例	一个读取本地Git历史的服务器	一个连接到Jira API的服务器

一次连接的生命周期 🤝

每个MCP连接都遵循一个清晰的、定义明确的生命周期，确保通信的有序和可靠。

初始化 (The Handshake)：这是连接建立后的第一步，也是最关键的一步。
- 客户端必须首先发送一个initialize请求。这个请求中包含了客户端支持的协议版本、自身的能力（capabilities）等信息。
- 服务器收到后，必须回复一个响应，其中包含服务器支持的协议版本和自身的能力。在这一步，双方会协商出一个共同支持的协议版本。
- 一旦服务器成功响应，客户端必须发送一个initialized通知，告知服务器：“我已经准备好了，可以开始正式通信了！”
  
  这个“三次握手”的过程确保了双方在开始交换数据前，对彼此的能力和协议版本达成了一致。
消息交换 (The Conversation)：初始化成功后，连接就进入了正常操作阶段。客户端和服务器可以自由地双向发送请求、响应和通知，执行协议定义的各种功能，如列出工具、读取资源等。
终止 (The Goodbye)：当通信结束时，需要关闭连接。MCP协议本身没有定义一个特定的关闭消息（如shutdown请求）。而是依赖于底层传输协议的机制来终止连接。
- 对于Stdio，通常由客户端关闭子进程的输入流，并等待其退出。
- 对于HTTP，任何一方关闭HTTP连接即意味着MCP连接的终止。

通过这套严谨的架构和通信协议，MCP为AI应用和外部世界之间搭建了一座坚固而高效的桥梁。

🛠️ MCP的超能力：核心功能全解析

理解了MCP的架构和通信基础后，现在让我们来探索它真正的“超能力”——那些让LLM变得更聪明、更能干的核心功能原语。MCP定义了五大核心概念：资源（Resources）、工具（Tools）、提示词（Prompts）、采样（Sampling） 和 根目录（Roots）。每一个都扮演着不可或缺的角色。

资源 (Resources) 📚: 赋予LLM一张图书馆借阅卡

这是什么 & 为什么重要？

资源（Resource）是MCP服务器向客户端暴露只读数据的方式。它就像是给了LLM一张可以访问巨大图书馆的借阅卡。这些数据可以是任何形式的上下文信息，比如：

文件内容（源代码、日志、文档）
数据库查询结果
外部API的响应
实时系统状态
截图或图片

通过资源，LLM能够突破其训练数据的时空限制，获取到完成任务所需的、实时的、领域特定的知识。

它是如何工作的？

URI标识：每个资源都由一个唯一的URI（统一资源标识符）来标识，例如 file:///path/to/doc.md 或 postgres://db/table/row。服务器可以定义自己的URI方案，提供了极大的灵活性。
资源发现：客户端如何知道有哪些资源可用？
- resources/list：客户端发送此请求，服务器返回一个静态的资源列表，每个资源都有URI、名称和描述。
- resources/templates/list：对于动态或海量的资源，服务器可以提供资源模板。例如，一个 file:///{path} 模板允许客户端通过填充 path 变量来构造任意文件资源的URI。
资源读取：客户端使用resources/read请求并提供资源的URI，服务器就会返回该资源的内容。内容可以是UTF-8编码的文本，也可以是Base64编码的二进制数据（如图片）。
资源更新：当资源发生变化时，服务器可以通过notifications/resources/list_changed通知客户端整个列表已更新。对于单个资源内容的频繁变化，MCP还支持resources/subscribe和resources/unsubscribe机制，实现高效的“订阅-通知”模式。

代码示例 (TypeScript)

下面是一个简单的MCP服务器，它暴露了一个本地的Markdown文档作为资源。这段代码修正并改进了原始草稿中的示例，采用了官方SDK推荐的现代写法。

TypeScript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { promises as fs } from "fs";

// 1. 初始化服务器
const server = new McpServer({
  name: "document-server",
  version: "1.0.0",
  capabilities: {
    resources: {
      // 声明支持资源功能
    },
  },
});

const resourceUri = "file:///project/docs/intro.md";

// 2. 注册资源列表处理器 (处理 resources/list 请求)
server.registerResourceProvider(async () => {
  return {
    resources:,
  };
});

// 3. 注册资源读取处理器 (处理 resources/read 请求)
server.registerResourceProvider(async (request) => {
  if (request.uri!== resourceUri) {
    // 如果请求的URI不是我们支持的，则返回空内容
    return { contents: };
  }
  
  // 异步读取文件内容
  const markdownContent = await fs.readFile("/path/to/your/intro.md", "utf-8");

  return {
    contents:,
  };
});

// 4. 连接传输层并启动
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.log("Document server started and connected via stdio.");
}

main();

工具 (Tools) 🧰: 让LLM学会使用电动工具

这是什么 & 为什么重要？

如果说资源是让LLM“能读”，那么工具（Tool）就是让LLM“能做”。工具是服务器向客户端暴露的可执行功能。它允许LLM执行带有副作用的操作，例如：

调用外部API（如发送邮件、查询天气）
在本地文件系统创建或修改文件
执行数据库的写操作
运行Shell命令

工具是实现真正“智能体（Agent）”行为的关键，它将LLM从一个对话模型转变为一个可以与外部世界交互并改变其状态的行动者。

它是如何工作的？

工具定义：每个工具都通过一个结构化的模式来定义，包含name（唯一名称）、description（给LLM看的功能描述）和一个非常重要的inputSchema（使用JSON Schema定义输入参数的格式和类型）。这个

inputSchema是LLM理解如何正确调用该工具的“说明书”。
工具发现：客户端通过tools/list请求来获取服务器上所有可用工具的列表及其定义。
工具调用：当LLM决定使用某个工具时，客户端会发送tools/call请求，其中包含工具的name和符合inputSchema的arguments。服务器执行相应操作后返回结果。

代码示例 (TypeScript)

这是一个实现简单数学计算工具的服务器示例，同样修正并优化了原始代码。

TypeScript

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod"; // 使用Zod进行模式验证

// 1. 初始化服务器
const server = new McpServer({
  name: "math-server",
  version: "1.0.0",
  capabilities: {
    tools: {}, // 声明支持工具功能
  },
});

// 2. 注册工具
server.registerTool(
  "calculate_square_root", // 工具的唯一名称
  {
    title: "Square Root Calculator", // 用户友好的显示名称
    description: "Calculates the square root of a given number.",
    inputSchema: {
      num: z.number().describe("The number to calculate the square root of"),
    },
  },
  async ({ num }) => { // 处理器接收解构后的、经过验证的参数
    if (num < 0) {
      // 返回一个工具级别的错误
      return {
        isError: true,
        content: [{ type: "text", text: "Cannot calculate square root of a negative number." }],
      };
    }
    const result = Math.sqrt(num);
    return {
      content:,
    };
  }
);

// 3. 连接传输层并启动
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.log("Math server started and connected via stdio.");
}

main();

值得注意的是，MCP为工具设计了一套精妙的错误处理机制。当工具调用失败时，有两种不同的错误类型。一种是协议层面的错误，比如方法名不存在或参数格式错误，这会返回一个标准的JSON-RPC错误。另一种是工具执行层面的错误，比如上面代码中计算负数平方根的场景。这种错误会以一个isError: true的成功响应形式返回。这种区分至关重要，因为它为智能体提供了恢复和推理的能力。当LLM收到一个工具执行错误时，它可以理解失败的原因（“哦，我不能给负数开方”），然后调整策略并尝试再次调用，而不是简单地因协议错误而卡住。这正是构建强大、有韧性的AI智能体的关键所在。

提示词 (Prompts) 📝: 创建可复用的AI工作流

这是什么 & 为什么重要？

提示词（Prompt）在MCP中是一个特殊概念，它指的是一种可复用的、参数化的模板，用于引导用户和LLM完成特定的、预设好的工作流。你可以把它想象成应用程序中预置的“快捷指令”或“斜杠命令”（如

/translate）。

它解决了这样一个问题：对于一些常见但复杂的任务，每次都让用户从头开始写提示词效率低下且容易出错。MCP的提示词功能允许服务器开发者预先封装好最佳的交互模式。

它是如何工作的？

提示词结构：一个提示词模板定义了它的name、description以及一个arguments列表，每个参数都可以指定是否必需。
提示词发现：客户端通过prompts/list获取所有可用的提示词模板。
提示词获取与执行：用户选择一个提示词并填入参数后，客户端发送prompts/get请求。服务器接收到请求和参数后，会动态生成一个完整的、结构化的消息对象（包含role和content），这个消息对象可以直接发送给LLM来执行任务。

代码示例 (TypeScript)

以下是一个处理prompts/get请求的服务器逻辑，用于实现一个翻译提示词：

TypeScript

//... 接续服务器初始化代码...

// 注册一个翻译提示词模板
server.registerPrompt(
  "translate",
  {
    title: "Translate Text",
    description: "Asks the LLM to translate the given text to the expected language.",
    argsSchema: {
      text: z.string().describe("The text to translate"),
      language: z.string().describe("The target language (e.g., English, Spanish)"),
    },
  },
  ({ text, language }) => {
    // 根据参数动态生成发送给LLM的消息
    return {
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: `Please translate the following text to ${language}:\n\n---\n${text}\n---`,
          },
        },
      ],
    };
  }
);

提示词的内容可以是丰富的多模态信息，包括文本（text）、图片（image），甚至可以嵌入一个resource引用，从而在对话中无缝地整合服务器端的各种数据。

采样 (Sampling) 🎲: 当服务器需要LLM的大脑时

这是什么 & 为什么重要？

采样（Sampling）是MCP中一个非常强大且独特的功能。它颠覆了通常的请求流：不是客户端请求服务器，而是服务器请求客户端去调用LLM生成内容。

想象一个场景：一个工具需要分析一段复杂的日志（资源），并从中提取出结构化的错误报告。这个“分析和提取”的过程本身就需要LLM的推理能力。通过采样，这个工具（服务器）可以把日志内容打包，请求客户端的LLM（比如Claude 3.5）来处理，然后利用返回的结构化报告完成后续任务。

它是如何工作的？

发起请求：服务器向客户端发送sampling/createMessage请求。这个请求中包含了要发送给LLM的消息、对模型的偏好（modelPreferences，如偏好速度、成本还是智能）以及其他采样参数（如temperature。
用户审核：安全是第一位的。客户端（Host）在收到采样请求后，必须将其呈现给用户进行审核和批准。用户可以查看甚至编辑即将发送给LLM的提示，并对LLM生成的结果进行最终确认，然后才返回给服务器。这个“人在环路”（human-in-the-loop）的设计是采样功能安全性的基石。
返回结果：用户批准后，客户端将结果返回给服务器，服务器便可以利用LLM生成的内容继续它的工作。

这个机制的设计带来了巨大的好处。服务器开发者可以构建出需要AI能力的复杂工具，而无需自己维护和支付昂贵的LLM API密钥。所有的模型调用、成本和隐私控制都集中在用户侧的Host应用中进行管理。这极大地降低了构建智能工具的门槛，同时将控制权牢牢地交还给了用户。

根目录 (Roots) 🌳: 设定清晰的操作边界

这是什么 & 为什么重要？

根目录（Roots）是客户端向服务器建议的操作范围或工作空间。它通常是一个或多个URI列表（主要是

file://路径），用来告诉服务器：“嘿，我们现在的工作主要集中在这些文件夹里，请优先关注这里的内容。”

这在IDE等开发环境中尤其重要。当你在处理一个项目时，你希望AI助手的所有操作（如文件搜索、代码分析）都局限在这个项目目录内，而不是去扫描你整个硬盘。根目录就提供了这样一个清晰的、结构化的边界。

它是如何工作的？

能力声明与列表获取：支持此功能的客户端会在初始化时声明roots能力。服务器可以通过roots/list请求来获取当前客户端设置的根目录列表。
变更通知：如果用户在IDE中添加或移除了一个项目文件夹，客户端可以发送一个notifications/roots/list_changed通知，让服务器及时了解工作范围的变化。

虽然根目录主要是信息性的，服务器理论上仍可访问边界之外的资源，但一个行为良好的服务器应该严格遵守客户端提供的根目录建议，这既是协议的最佳实践，也是安全的重要一环。

原语	Emoji	核心目的	打个比方	主要发起方
资源 (Resources)	📚	提供只读的数据/上下文	一张图书馆借阅卡	客户端/LLM
工具 (Tools)	🧰	执行有副作用的动作	一套电动工具	客户端/LLM
提示词 (Prompts)	📝	可复用的、引导式的工作流	一张填空模板	用户
采样 (Sampling)	🎲	请求LLM进行一次创作或推理	向创意大师征求一个点子	服务器
根目录 (Roots)	🌳	定义操作的工作空间	为你的后院划定栅栏	客户端

🛡️ 安全第一：MCP世界的生存法则

MCP赋予了LLM前所未有的强大能力，但能力越大，责任和风险也越大。将AI模型连接到文件系统、数据库和外部API，无异于给了它一把可以打开无数扇门的钥匙。如果这把钥匙被滥用，后果可能不堪设想。因此，在设计和使用MCP时，必须将安全性作为最高准则。

双刃剑：能力与风险

MCP的强大之处在于其通用性——它可以连接任何东西。但这恰恰也是其风险所在。一个设计不当或恶意的MCP服务器可能会带来严重的安全问题，例如：

数据泄露：服务器可能读取本地敏感文件（如SSH密钥、密码文件）并通过网络发送出去。
恶意执行：服务器暴露的工具可能包含破坏性命令（如rm -rf /），如果被意外触发，将造成灾难性后果。
系统操纵：服务器可能利用其能力修改系统配置、安装恶意软件或进行其他未经授权的操作。

黄金法则：用户知情与控制是王道 👑

MCP协议设计的核心安全理念是：最终的控制权永远在用户手中。作为MCP生态的中心协调者，

Host应用（如Cursor, Claude Desktop）是抵御安全风险的最重要防线。它必须承担起“守门人”的职责，确保任何敏感操作都经过用户的明确授权。

明确的授权流程：对于任何工具的调用、资源的读取，尤其是那些涉及文件写入、API调用或网络访问的操作，Host应用都应该弹出清晰的、人类可读的授权请求。用户必须清楚地知道“哪个工具”正在尝试“做什么”，并有权批准或拒绝。
“YOLO模式”的警示：一些Host应用提供了“自动运行”或“YOLO (You Only Live Once) Mode”。这虽然方便，但也绕过了逐次授权的安全机制。用户在开启此类功能时，必须充分意识到他们正在将信任完全委托给AI和其调用的工具。
对采样的严格控制：对于Sampling请求，安全要求更为严格。用户不仅要能批准或拒绝请求，还应该能审查和编辑即将发送给LLM的提示内容，以及LLM生成后返回给服务器的结果。

关键攻击向量与防御策略

在MCP生态中，开发者和用户需要警惕几种常见的攻击模式：

恶意服务器 (Malicious Servers)：这是最直接的威胁。一个伪装成有用工具的服务器，其真实目的可能是窃取数据或破坏系统。
- 防御：Host应用应提供沙箱环境来限制服务器的访问权限。使用Roots功能来明确限制文件系统的访问范围。用户应只从可信的来源安装和使用MCP服务器。
工具欺骗与钓鱼 (Tool Squatting & Phishing)：一个恶意服务器可能会注册一个与合法工具名称或描述非常相似的工具（例如，将git_push伪装成giiit_push），以欺骗LLM或用户在不经意间调用它。
- 防御：Host应用的UI应该清晰地展示工具的来源服务器，帮助用户辨别。建立可信的服务器市场或注册中心，对服务器进行审查和签名，也是未来的一个重要方向。
目录遍历攻击 (Path Traversal)：当服务器处理文件相关的Resource或Tool时，如果不对用户提供的URI或路径参数进行严格清理，攻击者可能构造如file:///etc/passwd之类的路径来读取敏感系统文件。
- 防御：服务器开发者必须对所有输入路径进行规范化和验证，确保它们始终处于Roots定义的合法工作区内。

作为服务器开发者，你的责任

如果你正在构建一个MCP服务器，请牢记以下安全最佳实践：

验证所有输入：永远不要相信来自客户端的任何数据。对所有URI、参数和路径进行严格的验证和清理。
最小权限原则：你的服务器应该只请求它完成功能所必需的最小权限。如果你的工具只需要读取文件，就不要请求写入权限。
谨慎处理二进制数据：在处理上传或下载的二进制资源时，要警惕其中可能嵌入的恶意负载。
限制速率与超时：为防止滥用，应为工具调用和资源读取设置合理的速率限制和超时机制。
清晰的文档：在你的工具和资源的描述中，明确、诚实地说明它们会做什么，特别是当它们涉及文件操作、网络访问或API调用时。

安全是一个持续的过程，而不是一次性的任务。随着MCP生态的不断发展，所有参与者——协议设计者、Host应用开发者、服务器构建者和最终用户——都必须共同努力，才能在享受其强大功能的同时，构建一个安全、可信的AI交互环境。

✨ 总结与展望

我们已经全面地探索了模型上下文协议（MCP）的核心概念、架构、强大功能以及至关重要的安全考量。现在，让我们退后一步，总结其精髓，并展望它将为我们开启的激动人心的未来。

核心要点回顾

统一标准，终结混乱：MCP通过提供一个类似“AI的USB-C”的开放标准，解决了AI应用与外部工具集成的“M×N”难题，极大地提升了开发效率和系统的互操作性。
优雅的架构：其“Host-Client-Server”三层架构清晰地划分了职责，使得Host应用可以专注于用户体验和LLM编排，而Server则可以轻量、专注地提供特定功能。
强大的功能原语：通过Resources（数据）、Tools（动作）、Prompts（工作流）、Sampling（反向调用LLM）和Roots（边界）这五大支柱，MCP为构建真正有能力的AI智能体提供了完整且强大的工具箱。
安全为基石：协议从设计之初就强调用户控制和知情同意，将Host应用定位为安全守门人，为这个强大的生态系统建立了信任基础。

前路展望：智能体的未来已来

MCP的出现，其意义远不止于简化了几个API调用。它正在为下一代AI应用——即能够自主理解、规划并与数字世界和物理世界交互的智能体（Agents）——铺平道路。

多智能体协作系统 (Multi-Agent Systems)：未来，复杂的任务可能不再由单个AI完成。我们可以想象一个由多个专业智能体组成的“团队”：一个“研究智能体”负责用工具从网络和数据库中收集信息，一个“规划智能体”负责制定行动步骤，一个“执行智能体”负责调用API完成任务。MCP将成为它们之间共享工具、交换信息的通用语言，实现高效协作。
具身智能 (Embodied AI)：MCP的潜力不止于数字世界。它完全可以作为AI与物理世界交互的协议。想象一下，一个控制智能家居的MCP服务器，让你可以用自然语言对AI说：“如果我离开家并且外面在下雨，记得关窗。”或者，正如社区中已经出现的项目，通过MCP让AI直接控制复杂的专业软件，如3D建模工具Blender 或地理信息系统QGIS，让非专业人士也能通过对话完成专业创作。
自然语言成为终极UI (The End of the GUI?)：随着MCP在各类应用（尤其是IDE等开发者工具）中的深度集成，我们正在见证一种新的交互范式的崛起。未来，我们与复杂软件的交互方式可能不再是点击无数的菜单和按钮，而是通过自然语言与一个深度集成、无所不能的AI助手对话。你想部署一个网站？告诉它。你想分析一份财报？也告诉它。MCP就是让这一切成为可能的底层管道。

立即行动：加入这场变革

MCP不仅仅是一个由Anthropic发起的项目，它已经迅速获得了包括微软、OpenAI、Google DeepMind在内的整个行业巨头的支持和采纳，形成了一个充满活力的开源社区。

这场变革才刚刚开始，而你正身处其中。无论你是想为你的产品提供AI能力，还是想构建一个能被所有AI使用的强大工具，现在都是最好的时机。我们鼓励你：

阅读官方文档：深入了解协议的每一个细节。
探索官方SDK：使用TypeScript、Python或其他语言的SDK，开始构建你自己的客户端或服务器。
浏览和贡献服务器：在社区的服务器仓库中寻找灵感，或者将你自己的创意贡献出来，让整个生态因你而更强大。

MCP正在为我们描绘一个更加智能、更加互联、更加自动化的未来。这不仅仅是一次技术的迭代，更是一场交互的革命。欢迎加入，一起构建未来！

posted @ 2025-06-18 15:01 德育处主任阅读(97) 评论(0) 收藏举报

刷新页面返回顶部

k21vin

『MCP』模型上下文协议核心概念

🏛️ 深入MCP的核心：理解架构与通信

三个火枪手：Host, Client & Server 🧑‍🤝‍🧑

协议的神经系统：通信层 🧠

基础：JSON-RPC 2.0

MCP的语言：三种核心消息类型

消息的传递：传输层

一次连接的生命周期 🤝

🛠️ MCP的超能力：核心功能全解析

资源 (Resources) 📚: 赋予LLM一张图书馆借阅卡

工具 (Tools) 🧰: 让LLM学会使用电动工具

提示词 (Prompts) 📝: 创建可复用的AI工作流

采样 (Sampling) 🎲: 当服务器需要LLM的大脑时

根目录 (Roots) 🌳: 设定清晰的操作边界

🛡️ 安全第一：MCP世界的生存法则

双刃剑：能力与风险

黄金法则：用户知情与控制是王道 👑

关键攻击向量与防御策略

作为服务器开发者，你的责任

✨ 总结与展望

核心要点回顾

前路展望：智能体的未来已来

立即行动：加入这场变革

公告