MCP入门指南（一）：什么是Model Context Protocol？——从协议本质到核心工作流程Model Con

1. 为什么需要MCP？——协议的本质价值

痛点解决：传统AI开发中，模型与工具（如数据库、API）的强绑定导致迭代困难。MCP通过自然语言描述接口（如“获取用户年龄分布”）而非硬编码函数名，实现“一次开发，多模型通用”。
类比说明：
- USB接口：不同厂商设备插上即用 → MCP：不同模型/工具声明能力即可协作
- 示例：一个“天气查询工具”可同时服务GPT-4、Claude等模型，无需为每个模型单独适配

2. MCP与传统Function Calling的关键差异

特性	传统Function Calling	MCP协议
接口描述方式	代码函数签名（Python/JS）	自然语言（工具名+参数说明）
生态扩展性	需模型方主动集成	工具开发者自主发布
执行环境依赖	必须同进程	支持跨进程/跨网络

3. 核心组件分工

Host：大模型运行平台（如Claude），负责解析用户意图→选择工具
Client：协议中转层（如Cursor编辑器），管理Server生命周期

Server：工具实现方（你的Python代码），需满足：

# 伪代码示例：工具必须提供name/description/parameters
@tool
def get_weather(location: str):
    """查询实时天气 | location: 城市名称"""
    return {"temp": 25, "unit": "℃"}

4. 工作流程拆解（以“查询上海天气”为例）

工具选择阶段：
- Host分析用户提问 → 匹配注册工具中description含“天气”的Server
执行阶段：
- 通过STDIO（本地调用）或SSE（HTTP POST）发送{"location":"上海"}
结果解释阶段：
- Server返回JSON → Host将{"temp":25}转换为自然语言回复

5. 两种通信模式适用场景

STDIO模式：
- 优点：零延迟，适合文件操作等本地任务
- 限制：必须与Host同机器部署
SSE模式：
- 优点：跨网络调用，适合Web API类工具
- 示例：FastAPI封装的天气查询服务

下篇预告

《MCP开发环境搭建：从零配置Python MCP Server到第一个Echo工具》将手把手教你运行Simple-MCP-Server-with-Python，并实现工具热加载调试技巧。