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

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

目录

  1. MCP 概述与核心问题
  2. 协议架构与核心概念
  3. 三种核心能力模型
  4. 传输层详解
  5. 通信协议与生命周期
  6. MCP Server 工程实现
  7. MCP Client 开发
  8. 安全模型与认证授权

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 统一三件事：

  1. 统一工具调用协议 — 让模型访问工具时走标准结构，而非各家 function calling 格式
  2. 统一上下文访问方式 — 模型可按标准方式访问文件、数据库、API、本地资源
  3. 统一服务描述方式 — 所有能力都能被机器描述（类似 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 Protocoltools/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 三种能力的对比

维度ToolsResourcesPrompts
本质可执行函数可读取数据可复用模板
触发方模型应用程序用户
副作用可有无无
动态性动态发现动态订阅动态组合
类比API 调用文件读取模板引擎

4. 传输层详解

MCP 传输层是整个协议中最关键的部分之一，它决定了 MCP 的运行形态、性能边界、安全模型和部署方式。

4.1 传输层本质

MCP 传输层 = JSON-RPC 2.0 消息在"进程/网络之间可靠传递"的机制抽象层

它解决三个问题：

  1. 消息怎么发？（stdin / HTTP / WebSocket）
  2. 消息怎么序列化？（JSON-RPC）
  3. 如何维持会话与流式交互？

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"
  }
}

标准错误码：

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

6.5 关键设计原则

  1. MCP Server ≠ 应用 — 它只是"能力适配层"
  2. tools 必须纯函数化 — 输入 → 输出，避免隐式状态
  3. 所有 IO 必须显式声明 — 数据库/文件/API 都通过 tools/resources
  4. schema-first — 工具必须有严格 inputSchema
  5. 幂等设计 — 尽量保证重复调用产生相同结果

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企业运用全面知识点-进阶篇。

# 网络 # 人工智能 # 架构 # 开发语言 # python # 服务器
Logo
MCP技术社区

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

更多推荐

Google能索引，AI却抓不到

很多技术团队有个错觉：只要Google能正常收录，内容就没问题。但现实是，你的页面在Google搜索结果里好好的，在ChatGPT、Perplexity、Claude的答案里却像从未存在过一样。

avatar MCP技术社区
cover

Windows 下部署 New API 中转站全过程实录（含 6 个真实踩坑）

avatar MCP技术社区

初识智能体

在过去两年中，几乎所有人都体验过大语言模型（如 ChatGPT、Claude、DeepSeek）的强大能力：写周报、润色邮件、解答编程疑难。被动响应：你问一句，它答一句。如果你的 Prompt 没有写清楚约束条件，它无法主动追问或修正目标。知行脱节：大模型能用流畅的文字告诉你“如何部署一个高可用 K8s 集群”，但它无法替你登录服务器敲下命令、查看报错日志并自动回滚。信息孤岛：大模型的知识止步于预

avatar MCP技术社区