tip 读完这篇文章你会收获什么

• 彻底理解 MCP 的架构设计思想
• 掌握 Python / TypeScript 双语言 Server 开发
• 学会 Client 与 Server 的完整连接流程
• 了解资源订阅、动态工具、反向采样等高级特性
• 收获可直接落地的生产级代码模板:::

📖 目录

• . 什么是 MCP？
• . 为什么需要 MCP？
• . 主要架构
• . 主要概念详解
• . 传输机制
• . 动手实战：建立 MCP 服务端
• . 动手实战：建立 MCP 客户端
• . 服务端与客户端如何连接
• . Claude Code 中使用 MCP
• . 高级主题
• . 常见问题与调试
• . 常用方法

. 什么是 MCP？

MCP 是一个开放的、标准化的通信协议，用于在 AI 大语言模型与外部世界之间建立双向连接。

简单MCP 解决了 LLM 的 "信息孤岛" 问题——模型本身只知道训练数据中的内容，、文件程序、数据库或 API。其实，MCP 提供了一种标准方式，让模型能够：

• ✅ 调用外部工具
• ✅ 读取外部资源
• ✅ 使用预置提示模板
• ✅ 沙箱化安全执行

传统方式 vs MCP 方式

┌─────────────────────────────────────────────────────┐
│ 传统方式 │
│ │
│ AI 模型 ──── 定制胶水代码 ──── 工具 A │
│ ──── 定制胶水代码 ──── 工具 B │
│ ──── 定制胶水代码 ──── 工具 C │
│ │
│ 每个工具都需要单独集成。维护成本高 │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐ │ MCP 方式 │ │ │ │ ┌─────────────────┐ │ │ AI 模型 ◄────────│ MCP 客户端 │ │ │ └──────┬──────────┘ │ │ │ | │ ⬇︎ ⬇︎ ⬇︎ | │ ┌────▼────┐ ┌────▼────┐ ┌────▼────┐| │ │MCP 服务端│ │MCP 服务端│ │MCP 服务端├| │ | | | | | | ├────────▼────────| | | | | Resources | | | ├────────▲────────| | | | Tools | | | ╰─────────────────────╯ ╰────────────╯

统一标准，一次集成，处处可用

再看::，tip: **MCP 的本质** MCP 是一个 **标准化的中间层协议**。它在 AI 模型和具体工具之间建立了一个通用接口。让模型不需要关心工具的内部实现，也让工具开发者不需要针对每个模型做适配。这就是 “USB‑C 接口” 比喻的含义——所有设备用同一个接口通信。怎么说呢，::的观点是，

痛点分析 & 使用者需求

\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ "

痛点类别	传统方案缺陷	MCP 优势
集成成本↑N×M → O	每个工具都要写定制胶水代码；维护矩阵 N×M，成本高。	统一协议，一次编写即插即用；只需维护 N+M 条方法。
安全隔离不足 & 沙箱难实现	各方案自行实现安全沙箱；易漏网之鱼，	协议内置沙箱机制，自动隔离执行环境。
跨网站绑定限制	绑定特定网站/框架/语言；迁移困难，话说回来，	语言无关，网站无关；不过，一次编写可在任意宿主上运行。怎么说呢，
环境碎片化 & 可复用性低	社区共享程度低；每个人都自建服务器，	社区共享服务实例，插件式可复用。
维护成本高 & N×M 病毒式扩散	新增一项功能，需要改动多处代码。	增加功能只需注册到服务器或客户端，即可对所有宿主生效。

::warning 传统方案导致 M×N 的“集成灾难”。每增加一个新的工具或宿主，都要写一套适配层。 这导致团队在大规模应用时耗费大量人力与时间。从::来看，

两种方式的代码对比

# 🔴 传统方式：每个工具都要单独适配
def call_github_api:
# 100 行 GitHub 特定代码
pass
def call_database:
# 100 行数据库特定代码
pass
def call_file_system:
# 100 行文件程序特定代码
pass
# 🟢 MCP 方式：统一接口
# . 启动 MCPC 服务端
# . MCPC 客户端自动发现并连接
# . AI 模型通过统一接口调用所有工具

主要架构 

架构总览 
// Architecture diagram in ASCII art:

三层角色说明 


角色 
职责 
实例 



🏠 Host
运行 AI 模型、管理 MCPC 客户端、协调交互。Claude Desktop、VS Code、自定义 App 等。🟢 Client ： 与 Server 建立连接、协议路由、Tool discovery。使用 MCPC SDK 中 `Client` 类。⚙️ Server ： 暴露 Tools / Resources / Prompts，执行实际操作如文件程序操作、多云存储操作等。## 对应角示
ascii-art
Host ——► Client ——► Server ——► Tool/Resource/Prompt Provider ◄―←←←←←←←← ← ← ← ← ← ← ← ← ← ← ← ↔️↔️↔️↔️↔️↔️↔️↔️↔️↔️↔️⇽⇾⇽⇾⇽⇾⇽ ⇨ ⇦ ⇦ ⇦ ⇦ ⇦ ↩ ↪ ↩ ↪ ↩ ↪ ...
## 小结
* **Host**：AI 应用入口。* **Client**：桥梁，实现协议路由。* **Server**：真正执领域务逻辑。---

主要概念详解 

MCP 定义了T​ools 、 R​esources 、 P​rompts 三大原语。理解它们是掌握 MCC 的关键一步！下面逐一拆解这方面，

🛠️ Tools — 可被模型主动调用的 “函数”。类似 OpenAI Function Calling，但更通用、更安全。支持参数验证与返回结构化结果。
// 定义一个 “查询天气”的 Tool 示例：
{
name的观点是，"get_wear",description:"获取指定城市的实时天气信息",inputSchema:{
至于type，"object",properties:{
说到city，{type:"string"。description:"城市名称，如 'Beijing','Shanghai'"}},required:
}
}

- 使用 JSON Schema 校验输入 - 自动生成提示文本 - 支持异步返回结果 - 返回结构化 JSON 或纯文本皆可 - 对接后即可让任何 LLM 自动决定是否调用该 Tool。

- ⚡ 常见坑提示 – 若返回内容不是合法 JSON，则解析失败导致整个请求挂掉！请务必确保 `` 标签内输出严格符合 JSON 标准。其实，

Tools 执行流程简图：
// Diagram simplified steps:
使用者提问 → AI 分析意图 → 判断是否需 Tool → Client 发起 tool_call →
Server 执行 Tool → 返回结果 → Host 接收并展示给使用者。---

📁 Resources — 可被模型读取但不可修改的数据对象，以 URI 标识。可包含多种 MIME 类型，如 `application/json`,`text/plain`,`image/png` 等。于 LLM 的 “文件程序”。用途包括查询数据库表结构、本地配置文件等。**
// Resource 示例：
{
从uri来看，"db://schema/users",name:"Users Table Schema",description:"users 表列定义及说明"。mimeType:"application/json"
}
// Resource 内容返回示例：
{
contents:
}
}]
}

。

---