什么是MCP？将AI应用与工具及数据相连
MCP基础：主机、客户端与服务器，工具发现功能，可从ChatGPT调用的Neo4j服务器，代理流程，以及模型上下文协议的安全边界所在。
来源: What Is MCP ? A Simple Guide to Connecting AI with Tools and Data
像ChatGPT这样的模型擅长阅读问题、撰写文本以及基于已有知识进行推理。然而，它们无法单独访问企业的数据库、应用程序、API、文档或工作流程。
模型上下文协议（MCP）是人工智能应用连接这些外部系统的标准方式。
MCP是什么
MCP是一种开放标准，使得人工智能应用能够安全且一致地连接到外部数据、工具、API和工作流程。
它是人工智能应用与其所需系统之间的共享通信层。借助MCP，助手不仅可以生成文本，还能获取数据、调用工具、执行搜索、运行已授权的操作，并将结果整合成答案。
支持MCP的助手可以：
- 搜索Google Drive中的文档
- 获取Slack消息
- 读取GitHub的源代码
- 查询企业数据库
因此，MCP 能将仅支持聊天的模型转变为能够操作真实服务的工具型助手。
MCP 诞生的原因
在 MCP 出现之前，各团队通常需要为每一对 AI 应用与系统单独构建定制化的集成方案。
连接 Slack 只是一个项目，而要连接 Drive、GitHub 或数据库则又是另一套方案。每次都需要重新处理认证机制、请求格式、响应方式、错误处理以及维护工作。
随着 AI 应用和企业系统的不断增加，这种分散式的集成方式已无法继续扩展。
MCP 为这类交互提供了一种统一的协议。无需让每个 AI 应用都学习不同供应商的专用接口，只需通过 MCP 服务器来暴露相关功能即可。
USB是一个很好的类比：一个接口，连接多种设备。MCP则是一种用于发现和使用工具及数据源的共享接口。
变革前后
变革前
在没有MCP的情况下，AI应用可能需要为每个平台——如Slack、Drive、GitHub、数据库以及企业应用——都建立直接的定制链接。各系统之间的耦合度很高，一旦API发生变化，就不得不修改集成代码；另一个AI应用往往也需要重新构建同样的连接机制。
变革后
借助MCP，各种功能都集中在标准化的服务器背后。AI应用通过MCP客户端进行交互，仅需一种协议即可发现各类工具：
AI Application → MCP Client → MCP Server → External Systems
重复的连接代码大幅减少，模型推理也与特定系统的代码分离。
MCP并不会取代底层的API。服务器仍然会通过各自的API来调用Slack、Drive、GitHub、数据库或企业平台。MCP只是标准化了这些功能在AI应用中的呈现方式。
核心组件
1. 用户
用户会用自然语言提出问题——例如，一个复杂的SiteScope故障排查问题，需要知识图谱关系、凭证、协议、连接性以及相关文档。他们无需了解模式、端点或查询语法。
2. MCP主机
主机是具备人工智能功能的界面：桌面助手、集成开发环境、聊天机器人、企业应用或智能体平台。它负责管理会话，并协调模型、MCP客户端、权限及用户体验。
3. MCP客户端
客户端负责维护从人工智能应用到服务器的连接，发现可用功能，并发送结构化的工具调用请求。一个主机可以同时为多个服务器运行多个客户端。
4. 人工智能模型或智能体
该模型能够识别用户意图，并判断是否需要外部数据或执行特定操作。像 LangGraph 这样的智能体框架可负责处理推理流程、状态管理、路由选择、工具挑选以及多步骤任务。
5. MCP 服务器
该服务器会提供选定的工具——包括查询功能、文档获取、计算功能以及业务操作功能。一个基于 Neo4j 的知识图谱 MCP 服务器可能会提供：
neo4j_get_schema——标签、关系类型、属性及架构信息neo4j_read_cypher——仅支持只读的 Cypher 语句；不支持CREATE、MERGE、DELETE、SET等命令，也不支持管理指令或PROFILE功能
该服务器会将标准的 MCP 请求映射为系统特定的操作。
6. 外部系统与 API
即实际的存储和操作工具：数据库、搜索系统、文档处理工具、协作工具、云服务以及企业级应用。
通话流程
典型的路径包括用户、MCP客户端、LangGraph（或类似工具）、模型、MCP服务器以及外部API。
- 用户提交自然语言请求。
- MCP客户端展示服务器的功能；该请求进入智能体工作流。
- 调度系统分析请求内容，可能让模型确定意图和所需工具。
- 模型从MCP工具中选择合适的工具——例如当用户需要查询数据库中的文档列表时，就会使用
neo4j_get_schema。 - 智能体会带着参数发送结构化的工具调用请求。
- 服务器将该请求转换为API调用、查询、搜索或其他系统操作。
- 外部系统返回结果。
- 服务器将结果格式化后传回给AI应用。
- 模型将工具返回的结果转化为清晰的答案。
- 用户无需了解API或查询语法即可看到答案。
实际案例：ChatGPT ↔ Neo4j
某组织将技术文档存储在Neo4j知识图中。通过Neo4j MCP服务器，ChatGPT可以查询图中的关系，并将结果转化为自然语言。用户可能会询问监控故障的潜在原因以及优先级的故障排除步骤。ChatGPT会进行解析，调用相应的Neo4j工具，执行受控的Cypher查询，然后以有依据的答案回应。MCP起到了桥梁作用。
优势
- 标准化集成——统一的工具/数据暴露方式。
- 更快的开发速度——只需构建工具和业务逻辑，无需不断编写适配器。
- 可重用性——一台服务器即可为多个兼容的AI应用提供服务。
- 职责分离——模型负责推理，服务器则处理外部访问。
MCP与智能代理AI
相比简单聊天机器人，智能代理更需要MCP。聊天机器人主要基于当前上下文回复，而智能代理会选择工具、调用它们、读取结果，并持续执行直至任务完成。MCP是标准的工具层，工作流则由调度器管理：
User request
↓
Agent interprets the goal
↓
Agent selects an MCP tool
↓
MCP server accesses an external system
↓
Agent evaluates the result
↓
Final response or next action
复杂任务可能需要串联多个MCP工具：查找文档、获取详细信息、评估风险、寻找相关文档，最终生成报告。
安全性
在没有控制措施的情况下公开工具是不安全的。生产环境应具备强大的身份认证与授权机制、针对每个工具的最小权限设置、输入验证功能、防止命令注入的防护措施、对敏感操作的人为确认流程、审计日志、安全的凭证存储方式、机密数据过滤功能，以及超时限制、访问频率控制与错误处理机制，同时还需严格区分只读工具和写入工具。
模型不应拥有对所有连接系统的无限制访问权限。每个工具只需暴露其功能所需的信息即可。
协议而非模型
MCP既不是模型，也不是智能体框架。
- 语言模型负责理解并生成语言。
- 智能体框架负责规划、状态管理以及多步骤控制流程。
- AI应用中的客户端会向服务器建立连接会话。
- 服务器则负责展示各种工具和资源。
MCP是一种共享的通信机制，使得这些组件能够协同工作。
总结
MCP为具备工具功能的互联人工智能提供了可重复使用的基础。它通过标准化工具、数据和工作流的发现与使用方式，减少了集成工作的复杂性。组织只需通过MCP服务器一次公开相关功能；智能体便可选择工具、获取所需数据、执行已授权的操作，并以自然语言进行回复——无需再手动将每个人工智能应用与企业平台逐一连接。
在评审时需明确这一概念：MCP负责标准化功能的发现与调用，而现有的API仍在服务器端执行实际任务。正是这种分离机制使得N+M扩展模式成为可能，且无需假装供应商已消失。
在架构评审中考虑MCP
需考虑每种功能是作为单个助手内的一次性函数实现，还是通过可重用的MCP服务器来实现。如果未来一个季度内会有其他客户端需要访问相同的GitHub、图数据或工单系统，应选择服务器方案；仅用于临时测试的原型才适合使用本地函数。
需明确界定信任边界：认证机制、最小权限原则、审计日志以及写入操作的人为审批流程都应体现在服务器端，而非提示文本中。只读型的Cypher工具和模式管理工具便是这种分离方式的典型示例。
对于基于智能体的工作流程，需记录正常执行路径和故障处理路径：当工具超时、返回空结果或拒绝未经授权的写入操作时，应如何应对。MCP虽规范了调用格式，但具体的操作流程仍需在运行手册中详细说明。
最后，需提醒相关方：MCP只是连接工具，并非魔法——Slack和Neo4j在服务器背后仍使用各自的API。其优势在于无需再为不同的助手创建N×M个专用适配器，同时能让供应商的API保持在应有的位置。
发现与模式工具
当采用Neo4j风格的服务器提供模式定义及只读查询工具时，模型可以先学习标签与关系，再提出有约束条件的查询。这种两步流程比直接将支持写入的Cypher语句放入提示语中更为安全。请明确记录哪些工具会修改状态，哪些则不会。
多服务器主机
那些需要同时使用Drive、Slack以及图数据库的主机，通常会并行运行多个MCP客户端。需为每台服务器设置独立的权限，避免代码助手的GitHub令牌随仅涉及Slack的请求一同被传递。MCP让多服务器架构变得常见，但身份认证设计仍需由你负责。