MCP实战解析：AI Agent工具调用的API、服务器与权限架构

从软件架构视角理解Agent工具调用

当AI Agent需要真正"做事"——读取代码、提交PR、查询数据库时，它不能直接拥有无限制的系统访问权。这正是MCP（Model Context Protocol，模型上下文协议）要解决的核心问题。本文基于一堂以软件架构师视角展开的MCP教学课程（Session 3），梳理工具、服务器、注册表与权限之间的设计关系。

讲师的切入点很有意思：先用GitHub API作为范例，说明API如何"暴露"GitHub的正常工作模型。一个Agent要完成任务，链路是这样的：Agent + API客户端 → 授权作用域令牌（scope token）→ Git引用/工作分支 → 内容与提交 → Pull Request可审阅提案。换句话说，Agent必须先通过带作用域的令牌完成授权，才能访问代码、文档乃至API本身。

这里有一条值得记住的原则：一个工具只有在被正确配置、且其凭证允许该操作时才有用。如果工具的凭证不允许某个操作，Agent就无法授权使用这个工具——权限决定了能力边界。

MCP：把工具安全地包装起来

讲师强调，工具应当始终被封装在MCP服务器中，这样才能在运行时被安全调用。MCP的价值在于让工具"按需被调用"，在真正需要时才执行相应功能，从而保证操作的安全性。

一个关键设计准则是：发现（Discovery）、权限（Permission）、策略（Policy）与运行时资产（Runtime Assets）必须相互分离，不要混为一谈。具体来说：

• MCP服务器要能够发现工具；
• MCP服务器要通过权限策略获得调用并交付工具的权限；
• Agent即便拿到了客户端交付的工具，仍需拥有访问该工具的运行时资产。

这套链路的起点是组织策略（Organization Policy）。它定义了Agent拥有的权限级别，以及MCP中被批准的服务器清单。组织策略授权服务器通过客户端向Agent交付工具。接着是注册表（Registry）——它保存服务器目录；再加上AI客户端，让Agent得以发现和调用工具。最终，MCP服务器生成结构化请求，内含来自服务器的工具，并指向底层的服务API或本地资源。

真正交付给Agent的，是底层服务——函数、API或本地资源。你也可以把本地数据库API、应用API或企业ERP API存放在MCP服务器中，让Agent在运行时安全地检索它们。

MCP（Model Context Protocol）是由Anthropic于2024年底发布的开放标准协议，旨在为AI模型与外部工具、数据源之间的交互提供统一接口。在MCP出现之前，每个AI应用都需要为不同的外部服务单独编写集成代码，形成大量重复的"M×N"集成矩阵；MCP将这一问题简化为标准化的"M+N"连接模式——模型只需支持MCP客户端，工具提供方只需实现MCP服务器，双方即可互通。MCP在架构上借鉴了语言服务器协议（LSP）的思路：定义一套标准的JSON-RPC消息格式，让宿主应用（Host）通过客户端与服务器通信，服务器再代理访问底层资源。这种分层设计使得权限控制、审计日志和工具版本管理都可以在协议层统一实施，而无需侵入每个工具的实现细节。

本地与远程MCP服务器的运行时差异

本地MCP与远程MCP使用不同的运行时，这是部署时必须厘清的一点：

• 本地MCP服务器：访问本地部署的应用，如on-prem数据库或内网应用。它以本地进程或端点形式运行，可以暴露本地文件和自定义工具，常用的传输方式是 stdio。安全上，依靠本地进程权限来限定影响范围。
• 远程MCP服务器：连接互联网，可对接组织外部、托管在云端的应用。它运行在网络端点之后，只能通过HTTP传输连接客户端，并使用认证来授权服务访问。安全上，依靠网络与双重策略来限制可达范围。

两者的共同要求是：明确的信任关系（explicit trust）和收窄的能力集合（narrow capability set）。讲师给出的一个官方远程端点范例是 GitHub 的 https://api.github.com 对应的MCP端点。

stdio（标准输入/输出）传输方式是本地MCP服务器最常用的通信机制：宿主进程以子进程方式启动MCP服务器，通过标准输入流发送请求、从标准输出流读取响应。这种方式天然继承了操作系统的进程隔离与用户权限模型，服务器能访问的文件和资源受限于启动它的用户账户，无需额外的网络暴露。远程MCP服务器则采用基于HTTP的服务器发送事件（SSE）或Streamable HTTP传输，请求需经过TLS加密和身份认证，适合多用户共享或跨网络边界的场景。选择传输方式时，核心判断标准是资源的物理位置与信任边界：在同一台机器上运行的工具优先用stdio以降低攻击面，需要跨网络访问的服务则必须通过HTTP传输并配合严格的认证机制。

注册表策略：控制服务器准入

注册表中保存着Agent可调用的工具清单及其功能描述——基本包含名称、描述、功能三要素。讲师特别指出，仅注册表级别的策略需要成功的服务器身份（server identity）：当你为MCP服务器及其工具设计策略、希望服务器在运行时有权向Agent交付这些工具时，必须赋予服务器身份才能执行动作。

课程列举了几个注册表API要求及其实际含义：

• GET /v0.1/servers：列出可发现的服务器；
• GET /v0.1/servers/{name}/versions/latest：返回当前条目；
• GET /v0.1/servers/{name}/versions/{version}：返回特定版本；
• registry-only + 匹配的 server id：将使用限制在已注册的条目内。

这里的核心抉择是 allow all 与 registry-only 的对比。allow all 意味着服务器可以在注册表中执行任何操作，但你将无法追溯Agent到底调用了哪些工具。而 registry-only 则实现了"收窄准入"——在注册表层级实施服务器身份与权限后，你可以轻松地把交付给某个Agent的工具追溯到具体来源。讲师的建议非常明确：在注册表层级实施服务器身份，不要用 allow all。

控制MCP服务器的"爆炸半径"

最后一节讨论了一个安全隐喻——MCP服务器会扩大"爆炸半径"（blast radius）。因为服务器一旦被授权，就能连接到应用（无论是否足够安全），它实际上在你的on-prem/远程应用与Agent之间架起了桥梁。于是每一个新服务器都是一条通往数据与操作的新路径。这意味着：开发新服务器时，必须同时定义它被允许在运行时暴露的工具。

讲师给出了几条收缩爆炸半径的设计原则：

工具命名空间：精确授权而非通配

不要用宽泛的通配符（wildcard）把大量操作塞进一个无名工具。让每个工具都拥有名称、描述和功能——当工具被调用并执行操作后，你能凭名称立即识别出它做了什么，便于审计和追踪。

认证：只向需要的组件注入运行时凭证

服务器不应对其中存储的所有API或工具都能认证，而应只认证当前运行时真正需要的那一个。举例来说，若Agent只需要数据库A的信息，而MCP服务器同时暴露了数据库A、B、C的内容，Agent就会收到过量信息，服务器也可能泄露本不该暴露的内容。正确做法是让服务器只认证并调用当下所需的特定工具。

变更控制与只读默认

对网络、数据目的地、敏感输入与返回内容实施审查；对服务器更新和工具列表扩张进行变更控制，警惕有风险的依赖。本节的关键要点是：批准只读的issue查询，而不开启仓库写权限。服务器不应被允许修改工具、数据库或应用，它应当只做认证、检出并检索所需信息，再交付给客户端。

这样一来，你就是在"强开发治理"之下实现一个受限上下文（bounded context）——这正是让AI Agent既能干活、又不至于失控的工程基础。

"爆炸半径"（blast radius）是安全工程中描述故障或攻击事件影响范围的常用术语，源自零信任安全架构的设计理念。在AI Agent场景下，爆炸半径的扩大主要来自两个方向：一是过度授权（Agent拥有比完成任务更多的权限），二是工具边界模糊（单个MCP服务器暴露了过多不相关的操作）。最小权限原则（Principle of Least Privilege）要求每个组件只被授予完成其特定任务所需的最小权限集合，这在传统软件系统中已是成熟实践，但在Agent系统中执行难度更高——因为Agent的行为路径难以预测，很容易在"为了方便"的心态下授予宽泛权限。将服务器按功能域拆分（如"只读查询服务器"与"写操作服务器"分开部署）、为每个服务器单独申请凭证，是将最小权限原则落地到MCP架构中的具体手段。

小结

Session 3 的主线清晰：API暴露工作模型，MCP封装并安全交付工具，注册表控制准入，而权限设计决定了Agent能力的边界。对于想把Agent接入真实系统的开发者而言，"发现/权限/策略/运行时分离""registry-only而非allow all""只读而非写权限"这三条，是最值得先落地的工程纪律。