MCPModel Context Protocol企业运用全面知识点 — 基础篇本篇涵盖协议原理、架构设计、核心能力、传输层、通信协议、Server/Client 工程实现与安全模型。进阶内容见 MCP企业运用全面知识点-进阶篇。目录MCP 概述与核心问题协议架构与核心概念三种核心能力模型传输层详解通信协议与生命周期MCP Server 工程实现MCP Client 开发安全模型与认证授权1. MCP 概述与核心问题1.1 什么是 MCPMCPModel Context Protocol模型上下文协议是由 Anthropic 于 2024 年 11 月提出的开放标准协议旨在标准化大模型LLM与外部工具/数据源之间的连接方式。一句话定义让所有 AI 应用都用同一种插拔式接口访问工具、数据和上下文而不是每个系统各写一套集成方式。官方定义MCP 是一个开放协议为应用程序向 LLM 提供上下文和工具提供了标准化方式。可以将其理解为 AI 应用的USB-C 接口——一个通用标准让模型能以统一方式连接各种数据源和工具。1.2 为什么需要 MCP核心问题在 MCP 出现之前大模型接入外部能力面临严重的碎片化问题问题描述集成成本高N×MN 个模型 × M 个工具每个组合都需要独立适配接口不统一每个工具都有自己的 SDK 和调用方式上下文传递混乱prompt 拼接 / function calling / plugin 格式各异难复用为 LangChain 写的工具无法用于 AutoGPT安全控制缺失缺乏标准化的权限和安全控制机制工具难以跨模型迁移针对 GPT 的 function calling 无法直接用于 Claude1.3 MCP 的设计目标MCP 统一三件事统一工具调用协议— 让模型访问工具时走标准结构而非各家 function calling 格式统一上下文访问方式— 模型可按标准方式访问文件、数据库、API、本地资源统一服务描述方式— 所有能力都能被机器描述类似 OpenAPI但更通用1.4 MCP 的设计哲学本地优先Local-first优化本地工具编排而非分布式服务调用模型无关不绑定任何特定 LLMGPT/Claude/Llama/本地模型均可接入可组合性工具应该像 CLI 工具一样可组合标准化一次开发到处运行2. 协议架构与核心概念2.1 整体架构┌──────────────────────────┐ │ MCP Host宿主 │ ← Claude Desktop / IDE 插件 / Agent 框架 │ ┌────────────────────┐ │ │ │ MCP Client │ │ ← 连接 Server、管理会话、发起请求 │ └────────┬───────────┘ │ │ │ Transport │ ← stdio / Streamable HTTP / WebSocket │ ┌────────▼───────────┐ │ │ │ MCP Server │ │ ← 暴露 Tools / Resources / Prompts │ └────────┬───────────┘ │ │ │ │ │ 外部系统 / API / DB │ └──────────────────────────┘2.2 三大核心组件组件职责示例MCP Host运行 LLM、管理 MCP Client、提供用户交互界面Claude Desktop、VS Code 插件、IDE AgentMCP Client连接 MCP Server、发起请求、管理会话和协议协商嵌入在 Host 中的协议适配层MCP Server暴露工具/资源/提示模板、执行调用逻辑把任何外部能力包装成标准 API 的适配层关键理解MCP Server ≠ 应用它只是能力适配层。2.3 MCP 的分层架构┌─────────────────────────┐ │ Application Layer │ ← tools / resources / prompts ├─────────────────────────┤ │ Protocol Layer │ ← JSON-RPC 2.0 消息规范 ├─────────────────────────┤ │ Transport Layer │ ← stdio / Streamable HTTP / WebSocket └─────────────────────────┘层级作用MCP Protocoltools/resources/prompts 规范JSON-RPC消息结构请求/响应/通知Transport传输方式stdio/HTTP/WSMCP Server执行逻辑3. 三种核心能力模型MCP 统一的不是工具而是三类抽象3.1 Tools工具可执行函数 — 由模型触发的操作特点有输入输出由模型触发调用类似 function calling可以有副作用写数据库、发邮件等示例结构{name:get_weather,description:获取指定城市的天气信息,inputSchema:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}调用示例{name:get_weather,arguments:{city:Beijing}}返回示例{content:[{type:text,text:Beijing: 28°C, sunny}]}3.2 Resources资源可读取的上下文数据 — 不执行逻辑只提供数据特点不执行逻辑只提供数据支持 URI 风格访问可做访问控制由应用程序控制是否提供给模型示例file:///project/readme.md db://users/123 github://repo/owner/name/issues/42资源声明{uri:file:///project/readme.md,name:Project README,mimeType:text/plain,description:项目说明文档}3.3 Prompts提示模板可复用 prompt 模板 — 将 prompt 工程标准化特点把 prompt 工程标准化而非写死在客户端支持参数化模板支持动态资源嵌入示例{name:code_review,description:代码审查提示模板,arguments:[{name:code,description:待审查的代码,required:true},{name:language,description:编程语言,required:false}]}3.4 三种能力的对比维度ToolsResourcesPrompts本质可执行函数可读取数据可复用模板触发方模型应用程序用户副作用可有无无动态性动态发现动态订阅动态组合类比API 调用文件读取模板引擎4. 传输层详解MCP 传输层是整个协议中最关键的部分之一它决定了 MCP 的运行形态、性能边界、安全模型和部署方式。4.1 传输层本质MCP 传输层 JSON-RPC 2.0 消息在进程/网络之间可靠传递的机制抽象层它解决三个问题消息怎么发stdin / HTTP / WebSocket消息怎么序列化JSON-RPC如何维持会话与流式交互4.2 三种传输方式4.2.1 stdio Transport本地进程通信最常见、默认方式Client → spawn MCP Server process ↓ stdin JSON-RPC request ↑ stdout Server responds特性说明无网络纯进程通信延迟极低零 HTTP 开销安全性高无端口暴露生命周期绑定Client 控制 Server 进程消息格式每一行一个 JSON{jsonrpc:2.0,id:1,method:tools/list}工程要点必须逐行解析不能 buffer 整块 JSON必须 flush stdout否则 client 收不到严格 id 映射保证并发调用不乱序适用场景IDE 插件、桌面 AI 工具、本地 Agent 运行时4.2.2 Streamable HTTP Transport远程服务通信2025-03 版本引入完全替代了之前的 SSE Transport请求模型POST /mcp Content-Type: application/json Accept: application/json, text/event-stream { jsonrpc: 2.0, method: tools/call, params: { ... }, id: 1 }特性说明可远程部署云端 MCP Server可水平扩展无状态设计支持 SSE 流长任务可流式返回需要认证JWT / OAuth 2.1关键改进vs 旧 SSE Transport单一端点/mcp简化部署无状态请求支持水平扩展可选 SSE 流式响应内置会话管理Mcp-Session-Id适用场景SaaS 工具、企业 API Gateway、多用户 MCP Server4.2.3 旧的 SSE Transport已弃用2024-11-05 版本定义已在 2025-03 版本标记为弃用使用两个 HTTP 端点/sseServer → Client和/messagesClient → Server。由于有状态、不可水平扩展等问题被 Streamable HTTP 替代。4.2.4 传输方式选择指南场景推荐传输原因本地 IDE 插件stdio零延迟、无网络暴露个人 AI 桌面工具stdio进程级隔离、安全团队共享 MCP 服务Streamable HTTP可远程访问、多用户企业级 MCP 平台Streamable HTTP可扩展、可认证实时双向交互Streamable HTTP SSE支持进度推送4.3 为什么 MCP 不选 HTTP/2 或 gRPCMCP 选择 stdio JSON-RPC 而非更高级的协议是基于以下权衡维度MCP 选择原因运行时耦合低耦合HTTP/2 强绑定 TLS 连接管理工具模型可执行进程工具应该是函数而非服务调用模式高频短生命周期HTTP/2 overhead 反而变重安全模型进程级隔离stdio 天然 sandbox 入口部署成本极低无需网络基础设施核心哲学MCP 优先优化本地工具编排远程部署通过 Streamable HTTP 支持。5. 通信协议与生命周期5.1 JSON-RPC 2.0MCP 基于 JSON-RPC 2.0所有通信都是标准 JSON 结构。请求{jsonrpc:2.0,id:1,method:tools/call,params:{name:get_weather,arguments:{city:Beijing}}}响应{jsonrpc:2.0,id:1,result:{content:[{type:text,text:Beijing: 28°C, sunny}]}}通知Notification无返回{jsonrpc:2.0,method:notifications/progress,params:{progressToken:job-123,progress:40,total:100}}5.2 MCP 协议生命周期1. 初始化连接 Client → Server: initialize (capabilities 协商 版本握手) Server → Client: capabilities 响应 2. 工具发现Discovery Client → Server: tools/list Server → Client: 返回所有可用工具 3. 调用工具 Client → Server: tools/call Server → Client: 返回结果 4. 可选资源访问 Client → Server: resources/list Client → Server: resources/read 5. 可选提示模板 Client → Server: prompts/list Client → Server: prompts/get 6. 关闭连接 Client → Server: 关闭通知5.3 能力协商Capability Negotiation初始化时 Client 和 Server 交换各自支持的能力{protocolVersion:2025-03-26,capabilities:{tools:{listChanged:true},resources:{subscribe:true,listChanged:true},prompts:{listChanged:true},logging:{}}}5.4 流式通信与进度通知MCP 支持通过 Notification 实现流式交互进度通知{jsonrpc:2.0,method:notifications/progress,params:{progressToken:task-123,progress:50,total:100}}日志通知{jsonrpc:2.0,method:notifications/message,params:{level:info,data:Processing query...}}6. MCP Server 工程实现6.1 MCP Server 最小接口集合一个可用的 MCP Server 至少要实现方法必要性说明initialize必须握手与能力协商tools/list必须返回工具列表tools/call必须执行工具调用resources/list可选返回资源列表resources/read可选读取资源内容prompts/list可选返回提示模板列表prompts/get可选获取提示模板6.2 Node.js 实现使用官方 SDKimport{McpServer}frommodelcontextprotocol/sdk/server/mcp.js;import{StdioServerTransport}frommodelcontextprotocol/sdk/server/stdio.js;import{z}fromzod;constservernewMcpServer({name:my-server,version:1.0.0,});// 注册工具server.tool(add,两个数字相加,{a:z.number(),b:z.number()},async({a,b})({content:[{type:text,text:String(ab)}],}));// 注册资源server.resource(config,config://app,async(uri)({contents:[{uri:uri.href,text:app config content}],}));// 注册提示模板server.prompt(code_review,{code:z.string()},async({code})({messages:[{role:user,content:{type:text,text:审查代码:\n${code}}}],}));// 启动consttransportnewStdioServerTransport();awaitserver.connect(transport);6.3 Python 实现使用 FastMCPfromfastmcpimportFastMCP mcpFastMCP(my-server)mcp.tool()defadd(a:int,b:int)-int:两个数字相加returnabmcp.resource(config://app)defget_config()-str:获取应用配置returnapp config contentmcp.prompt()defcode_review(code:str)-str:代码审查提示模板returnf审查代码:\n{code}if__name____main__:mcp.run()# 默认 stdio 传输6.4 进阶设计要点6.4.1 工具注册表Tool RegistryconsttoolRegistry{add:({a,b})ab,multiply:({a,b})a*b,search:async({query})awaitsearchAPI(query),};6.4.2 Schema 验证必须做import{z}fromzod;constAddSchemaz.object({a:z.number(),b:z.number(),});6.4.3 异步工具真实场景常见asyncfunctionfetchWeather(city:string){constresawaitfetch(https://api.weather.com/${city});returnres.json();}6.4.4 错误规范化{jsonrpc:2.0,id:1,error:{code:-32603,message:Internal error}}标准错误码错误码含义-32700Parse error解析错误-32600Invalid Request无效请求-32601Method not found方法不存在-32602Invalid params无效参数-32603Internal error内部错误6.5 关键设计原则MCP Server ≠ 应用— 它只是能力适配层tools 必须纯函数化— 输入 → 输出避免隐式状态所有 IO 必须显式声明— 数据库/文件/API 都通过 tools/resourcesschema-first— 工具必须有严格 inputSchema幂等设计— 尽量保证重复调用产生相同结果6.6 推荐工程结构mcp-server/ src/ index.ts # 入口 transport/ stdio.ts # stdio 传输 http.ts # HTTP 传输 tools/ add.ts # 工具实现 weather.ts resources/ files.ts # 资源实现 prompts/ review.ts # 提示模板 registry.ts # 工具注册表7. MCP Client 开发7.1 Client 核心职责连接 MCP Server发起请求tools/call 等管理会话和生命周期处理通知和流式响应7.2 使用官方 SDK 开发 Clientimport{Client}frommodelcontextprotocol/sdk/client/index.js;import{StdioClientTransport}frommodelcontextprotocol/sdk/client/stdio.js;consttransportnewStdioClientTransport({command:node,args:[my-mcp-server.js],});constclientnewClient({name:my-client,version:1.0.0,});awaitclient.connect(transport);// 列出可用工具consttoolsawaitclient.listTools();// 调用工具constresultawaitclient.callTool({name:add,arguments:{a:1,b:2},});// 列出资源constresourcesawaitclient.listResources();// 读取资源constcontentawaitclient.readResource({uri:file:///readme.md});7.3 Client 配置在 MCP Host 中stdio 模式{mcpServers:{my-local-server:{command:node,args:[./mcp-server/index.js],env:{API_KEY:xxx}}}}远程 HTTP 模式{mcpServers:{my-remote-server:{url:https://api.my-mcp.com/mcp,headers:{Authorization:Bearer xxx}}}}8. 安全模型与认证授权8.1 安全挑战MCP 工具的本质是把系统权限暴露给 LLM因此安全是生产化的核心问题MCP Server 可执行 shell、读文件、调 DB、调外部 APILLM 可能被 prompt injection 攻击操纵工具调用链可能产生级联安全风险8.2 安全三层模型Layer 1: Process Sandbox进程隔离 ↕ Layer 2: Capability Sandbox工具级权限 ↕ Layer 3: Data Sandbox数据级隔离Layer 1: 进程隔离方式说明Docker / gVisor容器级隔离seccomp系统调用限制namespace命名空间隔离WASM未来趋势沙箱运行时限制无根文件系统访问、受限网络出口、CPU/内存配额Layer 2: 工具级权限{name:read_file,annotations:{permissions:[fs:read]}}if(!ctx.permissions.includes(fs:read)){thrownewError(forbidden);}Tool Annotations工具注解是 MCP 规范中定义工具安全属性的标准机制{name:delete_database,annotations:{title:删除数据库,readOnlyHint:false,destructiveHint:true,idempotentHint:false,openWorldHint:false}}Layer 3: 数据级隔离行级安全Row-level security数据脱敏Redaction过滤FilteringSELECT*FROMordersWHEREtenant_idcurrent_tenant8.3 OAuth 2.1 认证远程 MCP Server 标准MCP 2025-03 版本引入了基于 OAuth 2.1 PKCE 的认证框架这是远程 MCP Server 的强制标准。认证流程1. Client 发现 Server 的认证要求 2. Client 重定向用户到授权页面 3. 用户授权 4. Server 返回 Access Token 5. Client 在后续请求中携带 Token请求示例POST /mcp Authorization: Bearer eyJhbGciOiJSUzI1NiIs... Content-Type: application/json8.4 企业级授权管理EMA 扩展2026 版本引入了 EMAEnterprise MCP Authorization扩展支持集中式授权管理企业策略下发统一身份认证集成细粒度权限控制8.5 安全实践检查清单检查项说明远程 Server 必须启用 OAuth 2.1防止未授权访问使用 Tool Annotations 标注安全属性帮助 Client 做安全决策进程级沙箱隔离防止工具越权数据级租户隔离防止跨租户数据泄露Prompt Injection 防护输入验证 输出过滤工具调用审计日志可追溯8.6 学术研究发现安全现状约 40.55% 的远程 MCP 服务器无任何认证约 96.6% 的 OAuth 服务器存在动态客户端注册缺陷常见攻击Tool Poisoning、Shadowing、Rug Pull基础篇结束。进阶内容方案对比、企业部署、Agent 架构、高级系统设计、生态工具链、协议演进、快速参考见 MCP企业运用全面知识点-进阶篇。