返回知识库

AI 与提示 · 智能体与连接

模型上下文协议MCP

MCP 用统一插头连接客户端和外部工具。能发现能力,不等于已授权,更不等于这家 server 可信。

先认出这根已插上的插头,再看它到底授权了什么

下面就是客户端上的 MCP 连接器。默认连上只读文档;未授权删除会被拦;来路不明的 server 即使能发现工具也不能信。

客户端连接已连接 · 只读

docs-server

read_doc · search

发现 2 个只读工具,可查手册,不能改库。MCP 统一「怎么连、怎么发现」。连上不等于什么都能干。

原因:握手后 server 自报工具和 schema。下一步:试一次未授权的删除,看插头还在不在、文件会不会丢。

知识点:统一连接,不代替授权

插头上的发现列表和拦截章已经演过,这里只给命名。

  • MCP 用同一套握手连接不同 server,把「各写一套适配器」压成标准插头。
  • server 自描述工具和 schema,客户端按描述发现,而不是写死接口。
  • 能发现 ≠ 能调用 ≠ 被信任。写操作仍要权限和审批。
  • 它不是技能:技能是做法;MCP 是工具从哪来、怎么连上。

什么时候用、怎么用

同一个助手要接多种外部能力,又不想为每个应用各写一套适配器。

  • 信号:文档、仓库、日历各自对接,改一处要改 N 处。
  • 适用:只接可信 server,先只读,写操作逐次审批并留审计。
  • 不适用:把「已连接」当成授权完成;也不要用来代替工具调用本身。
  • 最短路径:选可信来源 → 握手发现 → 看清工具名单 → 越权就拦。

正反例:同一根插头,只差信不信

都连上了一家「文档 server」。

正例可信来源 + 只读工具

能查手册,删不了文件。权限边界写在连接上。

反例来路不明也能 send_money

握手成功被当成安全。协议不管供应商,信任要另做。

快速自测

MCP 客户端列出了 delete_doc。这是否表示现在可以删文档?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。