MCP 是 Agent 连接外部工具、数据和服务的桥梁，让模型能在受控接口下使用外部能力。

为什么 Agent 需要 MCP

模型本身不能天然访问你的浏览器、Figma、数据库、文档系统或企业内部工具。真实工程任务却经常需要这些能力：打开页面检查 UI、读取设计稿、查文档、读测试数据、接企业内部系统。

MCP 的价值就在这里：它把这些外部能力变成 Agent 可以理解和使用的受控入口。它解决的不是“模型会不会写代码”，而是“模型怎么安全地接到外部世界”。

基本角色

角色	作用	更像什么
MCP Client	Agent 所在应用，负责发起连接和消费能力	连接发起方
MCP Server	把外部系统能力包装成可调用接口	能力暴露方
Tool	让 Agent 执行动作，例如查数据、读设计、操作浏览器	动作接口
Resource	让 Agent 读取外部上下文，例如文件、文档、记录	可读上下文
Prompt	提供可复用的任务模板或上下文入口	任务入口

这里最容易混淆的是：很多人会把 MCP 直接等同于 Tool。实际上 Tool 只是 MCP 可能暴露出来的一种能力形态，Resource 和 Prompt 也可能通过 MCP 提供。

典型场景

• 浏览器 打开页面、点击、截图、验证 UI。
• Figma 读取设计稿、资产和组件信息。
• 文档 / PDF 读取需求、规格、表格、知识库和说明文档。
• 数据库 查询开发或测试数据。
• 企业内部系统 工单、监控、发布、知识库、内部平台。

你可以把这些场景理解成一个判断题：只要任务已经超出“读本地文件和跑本地命令”的范围，就要考虑是不是需要一个连接层，而不是让模型凭空猜测外部系统状态。

权限与边界

MCP 最需要强调的不是“能连什么”，而是“连上以后怎么控制风险”。

在真实项目里，至少要明确这几件事：

• 读取能力和写入能力要分开。
• 测试环境和生产环境要分开。
• 密钥、数据范围和审计日志要独立管理。
• 能调用，不等于应该默认允许调用。

MCP 不是无限授权

连接能力不等于可以随便操作。权限、审计、数据范围、密钥管理和误操作恢复，都需要在工具配置和项目规则里明确。

MCP 与 Tool 的关系

Tool 解决的是“Agent 怎么做动作”，MCP 解决的是“这些动作怎么安全地连到外部系统”。

它们的关系可以这样理解：

• MCP 常常会提供 Tool。
• 但 Tool 不一定都来自 MCP。
• 本地 Shell、文件编辑、apply patch 这类工具，就不一定依赖 MCP。
• MCP 的重点不是动作本身，而是外部能力接入的标准化和边界控制。

所以如果 Tool 是“手”，MCP 更像“把手伸向外部系统时的受控连接层”。

贡献者: sincerly90

上一页Skill：复用经验

下一页Tool：执行动作接口