MCP企业运用全面知识点-基础篇

AI-好学者

171人浏览 · 2026-07-04 23:26:44

AI-好学者 · 2026-07-04 23:26:44 发布

MCP（Model Context Protocol）企业运用全面知识点 — 基础篇

本篇涵盖协议原理、架构设计、核心能力、传输层、通信协议、Server/Client 工程实现与安全模型。
进阶内容见 MCP企业运用全面知识点-进阶篇。

1. MCP 概述与核心问题

1.1 什么是 MCP

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 于 2024 年 11 月提出的开放标准协议，旨在标准化大模型（LLM）与外部工具/数据源之间的连接方式。

一句话定义：让所有 AI 应用都用同一种"插拔式接口"访问工具、数据和上下文，而不是每个系统各写一套集成方式。

官方定义：MCP 是一个开放协议，为应用程序向 LLM 提供上下文和工具提供了标准化方式。可以将其理解为 AI 应用的"USB-C 接口"——一个通用标准，让模型能以统一方式连接各种数据源和工具。

1.2 为什么需要 MCP（核心问题）

在 MCP 出现之前，大模型接入外部能力面临严重的碎片化问题：

问题	描述
集成成本高（N×M）	N 个模型 × M 个工具，每个组合都需要独立适配
接口不统一	每个工具都有自己的 SDK 和调用方式
上下文传递混乱	prompt 拼接 / function calling / plugin 格式各异
难复用	为 LangChain 写的工具无法用于 AutoGPT
安全控制缺失	缺乏标准化的权限和安全控制机制
工具难以跨模型迁移	针对 GPT 的 function calling 无法直接用于 Claude

1.3 MCP 的设计目标

MCP 统一三件事：

统一工具调用协议 — 让模型访问工具时走标准结构，而非各家 function calling 格式
统一上下文访问方式 — 模型可按标准方式访问文件、数据库、API、本地资源
统一服务描述方式 — 所有能力都能被机器描述（类似 OpenAPI，但更通用）

1.4 MCP 的设计哲学

本地优先（Local-first）：优化本地工具编排，而非分布式服务调用
模型无关：不绑定任何特定 LLM（GPT/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 Agent
MCP 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 Protocol	tools/resources/prompts 规范
JSON-RPC	消息结构（请求/响应/通知）
Transport	传输方式（stdio/HTTP/WS）
MCP 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 三种能力的对比

维度	Tools	Resources	Prompts
本质	可执行函数	可读取数据	可复用模板
触发方	模型	应用程序	用户
副作用	可有	无	无
动态性	动态发现	动态订阅	动态组合
类比	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 Server

4.2.3 旧的 SSE Transport（已弃用）

2024-11-05 版本定义，已在 2025-03 版本标记为弃用

使用两个 HTTP 端点：/sse（Server → Client）和 /messages（Client → Server）。由于有状态、不可水平扩展等问题被 Streamable HTTP 替代。

4.2.4 传输方式选择指南

场景	推荐传输	原因
本地 IDE 插件	stdio	零延迟、无网络暴露
个人 AI 桌面工具	stdio	进程级隔离、安全
团队共享 MCP 服务	Streamable HTTP	可远程访问、多用户
企业级 MCP 平台	Streamable HTTP	可扩展、可认证
实时双向交互	Streamable HTTP + SSE	支持进度推送

4.3 为什么 MCP 不选 HTTP/2 或 gRPC

MCP 选择 stdio + JSON-RPC 而非更"高级"的协议，是基于以下权衡：

维度	MCP 选择	原因
运行时耦合	低耦合	HTTP/2 强绑定 TLS + 连接管理
工具模型	可执行进程	工具应该是"函数"而非"服务"
调用模式	高频短生命周期	HTTP/2 overhead 反而变重
安全模型	进程级隔离	stdio 天然 sandbox 入口
部署成本	极低	无需网络基础设施

核心哲学：MCP 优先优化"本地工具编排"，远程部署通过 Streamable HTTP 支持。

5. 通信协议与生命周期

5.1 JSON-RPC 2.0

MCP 基于 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 实现（使用官方 SDK）

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "my-server",
  version: "1.0.0",
});

// 注册工具
server.tool(
  "add",
  "两个数字相加",
  { a: z.number(), b: z.number() },
  async ({ a, b }) => ({
    content: [{ type: "text", text: String(a + b) }],
  })
);

// 注册资源
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}` } }],
}));

// 启动
const transport = new StdioServerTransport();
await server.connect(transport);

6.3 Python 实现（使用 FastMCP）

from fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def add(a: int, b: int) -> int:
    """两个数字相加"""
    return a + b

@mcp.resource("config://app")
def get_config() -> str:
    """获取应用配置"""
    return "app config content"

@mcp.prompt()
def code_review(code: str) -> str:
    """代码审查提示模板"""
    return f"审查代码:\n{code}"

if __name__ == "__main__":
    mcp.run()  # 默认 stdio 传输

6.4 进阶设计要点

6.4.1 工具注册表（Tool Registry）

const toolRegistry = {
  add: ({ a, b }) => a + b,
  multiply: ({ a, b }) => a * b,
  search: async ({ query }) => await searchAPI(query),
};

6.4.2 Schema 验证（必须做）

import { z } from "zod";

const AddSchema = z.object({
  a: z.number(),
  b: z.number(),
});

6.4.3 异步工具（真实场景常见）

async function fetchWeather(city: string) {
  const res = await fetch(`https://api.weather.com/${city}`);
  return res.json();
}

6.4.4 错误规范化

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32603,
    "message": "Internal error"
  }
}

标准错误码：

错误码	含义
-32700	Parse error（解析错误）
-32600	Invalid Request（无效请求）
-32601	Method not found（方法不存在）
-32602	Invalid params（无效参数）
-32603	Internal error（内部错误）

6.5 关键设计原则

MCP Server ≠ 应用 — 它只是"能力适配层"
tools 必须纯函数化 — 输入 → 输出，避免隐式状态
所有 IO 必须显式声明 — 数据库/文件/API 都通过 tools/resources
schema-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 开发 Client

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const transport = new StdioClientTransport({
  command: "node",
  args: ["my-mcp-server.js"],
});

const client = new Client({
  name: "my-client",
  version: "1.0.0",
});

await client.connect(transport);

// 列出可用工具
const tools = await client.listTools();

// 调用工具
const result = await client.callTool({
  name: "add",
  arguments: { a: 1, b: 2 },
});

// 列出资源
const resources = await client.listResources();

// 读取资源
const content = await client.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、调外部 API
LLM 可能被 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")) {
  throw new Error("forbidden");
}

Tool Annotations（工具注解） 是 MCP 规范中定义工具安全属性的标准机制：

{
  "name": "delete_database",
  "annotations": {
    "title": "删除数据库",
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": false,
    "openWorldHint": false
  }
}

Layer 3: 数据级隔离

行级安全（Row-level security）
数据脱敏（Redaction）
过滤（Filtering）

SELECT * FROM orders WHERE tenant_id = current_tenant

8.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/json

8.4 企业级授权管理（EMA 扩展）

2026 版本引入了 EMA（Enterprise 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企业运用全面知识点-进阶篇。

MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

AI Agent 入门与实战：从对话到干活，理解下一代AI工作方式

你告诉Agent一个目标，它会自己拆解成步骤，调用工具（文件操作、命令行、API接口），逐步执行，遇到问题会自己尝试修复，最后给你交付结果。第一，Agent写的代码不是100%可靠的。对于一个已经在写代码的开发者来说，现在最重要的事情不是"学什么新语言或新框架"，而是学会怎么让Agent帮你干活、提高你不可替代的那部分能力——业务理解、架构设计、技术判断。用Agent的做法是：你告诉它需求，它自己

MCP技术社区

MCP企业运用全面知识点-进阶篇

本文是MCP（Model Context Protocol）企业运用进阶指南，重点对比MCP与其他技术方案的差异，并详细阐述企业级部署方案。主要内容包括：技术方案对比：将MCP与Function Calling、OpenAI Plugins/Assistants API及传统REST/GraphQL API进行多维度比较，突出MCP在标准化、扩展性和上下文管理方面的优势。企业部署方案：提供从基

MCP技术社区

Typora插件开发指南：打造专属IDE式写作环境

MCP技术社区

所有评论(0)

查看更多评论

AI-好学者

@weixin_51955414

已为社区贡献2条内容

MCP企业运用全面知识点-基础篇

AI-好学者

MCP（Model Context Protocol）企业运用全面知识点 — 基础篇

目录

1. MCP 概述与核心问题

1.1 什么是 MCP

1.2 为什么需要 MCP（核心问题）

1.3 MCP 的设计目标

1.4 MCP 的设计哲学

2. 协议架构与核心概念

2.1 整体架构

2.2 三大核心组件

2.3 MCP 的分层架构

3. 三种核心能力模型

3.1 Tools（工具）

3.2 Resources（资源）

3.3 Prompts（提示模板）

3.4 三种能力的对比

4. 传输层详解

4.1 传输层本质

4.2 三种传输方式

4.2.1 stdio Transport（本地进程通信）

4.2.2 Streamable HTTP Transport（远程服务通信）

4.2.3 旧的 SSE Transport（已弃用）

4.2.4 传输方式选择指南

4.3 为什么 MCP 不选 HTTP/2 或 gRPC

5. 通信协议与生命周期

5.1 JSON-RPC 2.0

5.2 MCP 协议生命周期

5.3 能力协商（Capability Negotiation）

5.4 流式通信与进度通知

6. MCP Server 工程实现

6.1 MCP Server 最小接口集合

6.2 Node.js 实现（使用官方 SDK）

6.3 Python 实现（使用 FastMCP）

6.4 进阶设计要点

6.4.1 工具注册表（Tool Registry）

6.4.2 Schema 验证（必须做）

6.4.3 异步工具（真实场景常见）

6.4.4 错误规范化

6.5 关键设计原则

6.6 推荐工程结构

7. MCP Client 开发

7.1 Client 核心职责

7.2 使用官方 SDK 开发 Client

7.3 Client 配置（在 MCP Host 中）

8. 安全模型与认证授权

8.1 安全挑战

8.2 安全三层模型

Layer 1: 进程隔离

Layer 2: 工具级权限

Layer 3: 数据级隔离

8.3 OAuth 2.1 认证（远程 MCP Server 标准）

8.4 企业级授权管理（EMA 扩展）

8.5 安全实践检查清单

8.6 学术研究发现（安全现状）

所有评论(0)

温馨提示：您尚未绑定手机号

AI-好学者