MCP（Model Context Protocol，模型上下文协议）是由Anthropic在2024年底提出的一个开源标准协议，现在已经被多家厂商（包括OpenAI的部分兼容实现）和社区广泛接受。它本质上是给大模型提供了一个统一的、标准化的“后插拔接口”，让LLM可以安全、动态、可控地访问外部工具、数据源、文件系统、企业内部服务等，而不需要为每个工具都单独写Function Calling适配器。
简单类比：
- 以前的Function Calling / Tool Use 像每个手机品牌有自己的充电口（Lightning、Micro USB等）
- MCP 就像大家统一用上了USB-C，模型只要支持MCP，就能插上各种“充电器”（工具服务器）
我实际用过的一个典型MCP场景（生产环境中落地过的）
场景：企业内部的“智能知识助手 + 报销审批Agent”（2025年中上线的一个内部工具）
背景：
公司有Confluence知识库、Notion文档、内部飞书/企业微信审批系统、Jira任务、ERP报销单据系统。这些系统API都不一样，鉴权方式也不同（有的OAuth，有的API Key，有的内部Token），传统Function Calling写10多个tool描述很乱，而且模型一换（从Claude 3.5 → GPT-4o → DeepSeek-R1）就得重写tool schema。
我们怎么用MCP解决的（核心落地点）：
- 搭建了统一的MCP Server（用Python + FastAPI + MCP官方SDK实现），对外只暴露一个MCP endpoint（ws://或https://）。
这个Server内部做了“工具路由 + 鉴权桥接”：
- /confluence → 查询Confluence REST API
- /notion → Notion块查询 + 搜索
- /jira → 获取issue详情、评论、状态流转
- /approval → 调用飞书/企业微信审批接口
- /erp_reimburse → 读取用户最近报销单、提交新报销草稿
- 在Agent侧（基于LangGraph + DeepSeek-R1）：
- 不写一堆function calling schema
- 只配置一个MCP client，告诉模型：“你有一个MCP服务器可以连接，里面有这些capability（能力描述用自然语言 + 简单JSON schema）”
- 模型在思考时，如果需要外部信息，就通过MCP协议发请求 → MCP Server执行 → 返回结构化上下文（文本 + JSON + 部分文件片段）→ 塞回模型上下文
一个真实对话示例（用户是员工小A）：
用户：我上个月的差旅报销单在哪？审批到哪一步了？
Agent思考过程（简化）：
- 模型判断需要查报销记录 → 调用MCP → “get_my_recent_reimbursements” capability
- MCP Server收到请求，用用户身份Token去ERP查 → 返回最近5条记录的结构化JSON
- 模型拿到数据 → 再判断需要查审批流 → 又一次MCP调用 → “get_approval_status” → 飞书审批接口
- 最终回复：“你上个月的上海出差报销（ID: EXP-20251234）已提交财务，当前状态：审批中（部门经理已通过，等待财务确认）。链接：https://erp.company.com/xxx”
为什么这个场景MCP特别香（对比不用MCP的痛点）：
- 解耦：模型侧不用关心后端到底是飞书还是企业微信，换系统只要改MCP Server内部逻辑，Agent代码几乎不动
- 安全可控：MCP Server统一做鉴权、限流、审计日志、敏感数据脱敏（比如身份证号自动mask）
- 多模型兼容：同一个MCP Server，Claude、GPT、DeepSeek、Qwen都能用，切换模型成本极低
- 上下文质量高：不像传统tool call只返回一小段JSON，MCP允许返回大段Markdown、表格、文件片段，模型能更好地“理解”企业文档
- 可扩展：后来加了GitLab代码搜索、内部BI看板查询，都只在MCP Server加一个新capability，Agent侧零改动
一句话总结这个场景：
MCP把“工具乱七八糟、模型换来换去”的地狱难度，降到了“只维护一个中间层Server”的普通难度，特别适合B端企业Agent、知识库+审批+任务多系统打通的复杂场景。
如果你面试时被问到，可以直接说类似这个企业内部助手场景，面试官一般会觉得你不是背八股文、是真的落地过。
