AIUnlimited
🌳

AI基础

🌱
AI 种子

从零开始

🌿
AI 萌芽

打好基础

🌳
AI 枝干

付诸实践

🏕️
AI 树冠

深入探索

🌲
AI 森林

精通AI

🔨

AI精通

✏️
AI 草图

从零开始

🪨
AI 雕刻

打好基础

⚒️
AI 匠心

付诸实践

💎
AI 打磨

深入探索

🏆
AI 杰作

精通AI

📘

AI实战

📖
理解开源模型

开源模型的基础知识和资源

🎯
问题到模型任务

将业务问题转化为模型任务

⚡
跑通第一个模型

30分钟快速看到第一个结果

🔧
微调与评测

微调模型并评估性能

🚀
应用系统

构建实际AI应用系统

🎨
生成式AI

探索AIGC的开源模型

🤖
Agent智能体

学习Agent框架和MCP工具

📐
基础补充

LLM基础知识和评测

🎓

Claude 学院

🤖
Claude 101 入门

用 Claude 学习 AI 基础知识

💻
Claude Code 101 入门

让 Claude 成为你的结对编程伙伴

🤝
Claude Cowork 入门

与 Claude 协作完成复杂项目

⚙️
Claude 平台 101

使用 Claude API 构建应用

实验室

已加载 7 个实验
🧬神经网络沙盒🤖AI 还是人类?🥋提示工程道场🏁算法竞速🧠AI 知识挑战🏗️系统设计画布
🎯模拟面试进入实验室→
🚀

职业发展

🚀
面试发射台

开启你的旅程

🌟
行为面试精通

掌握软技能

💻
技术面试

通过编程轮次

🤖
AI与ML面试

ML面试精通

🏆
Offer与未来

拿下最好的Offer

立即开始
AIUnlimited

AI 教育平台

沪ICP备18025655号-11

学习

  • AI基础
  • AI实战
  • Claude学院
  • 实验室
  • 职业发展

社区

  • 关于
  • 常见问题

支持

  • 服务条款
  • 隐私政策
  • 联系我们
AI & 工程学习计划›🤖 Agent智能体›课程›MCP:让模型连接外部工具
🔌
Agent智能体 • 入门⏱️ 25 分钟阅读

MCP:让模型连接外部工具

get_weather是MS-Agent组合Server连接名称和工具名称后显示的标识。area与target_date`不是预先写死的调用参数,而是Qwen3-4B根据“杭州明天”生成的结构化参数。相关注册结果如下图所示。

正文配图

处理工具返回与最终回答

天气MCP收到参数后,将“杭州”解析为“杭州,浙江,中国”,根据当地时区把tomorrow转换为2026年9月7日,并返回:

{
  "requested_area": "杭州",
  "resolved_area": "杭州,浙江,中国",
  "date": "2026-09-07",
  "timezone": "Asia/Shanghai",
  "weather_code": 51,
  "weather": "小毛毛雨",
  "temperature_max_c": 29.0,
  "temperature_min_c": 21.6,
  "precipitation_probability_max_percent": 31,
  "wind_speed_max_kmh": 13.0,
  "data_source": "Open-Meteo"
}

Qwen3-4B随后依据这组结果生成自然语言回答,列出了实际匹配地区、日期、天气状况、最高和最低气温、降水概率及最大风速。至此,“理解问题—选择工具—生成参数—执行工具—处理结果”的调用链路完成。结合大模型执行结果如下:

正文配图

调用MCP广场中的fetch服务

完成托管和配置后,先直接连接服务并检查工具列表。下面的测试样例网站信息https://example.com。

async def direct_fetch_check():
    async with streamable_http_client(MCP_SERVER_URL) as streams:
        read_stream, write_stream, _ = streams
        async with ClientSession(read_stream, write_stream) as session:
            await session.initialize()
            tools = await session.list_tools()
            print("Server返回的工具:", [tool.name for tool in tools.tools])
            result = await session.call_tool(
                "fetch",
                arguments={
                    "url": "https://example.com",
                    "max_length": 1000,
                    "start_index": 0,
                    "raw": False,
                },
            )
            if result.isError:
                raise RuntimeError(str(result.content)
            for block in result.content:
                if getattr(block, "type", None) == "text":
                    print(block.text)

await direct_fetch_check()

实际运行时,Server公开了fetch工具,并返回了目标网页的正文片段和链接。这说明魔搭托管服务、Streamable HTTP连接以及网页抓取工具本身均可工作。直接连接魔搭托管fetch服务、发现工具并返回网页内容如下图所示。

正文配图

直接调用成功后,再复用前面配置好的Qwen3-4B,让模型自主选择工具:

fetch_agent = LLMAgent(
    config=agent_config,
    tag="fetch-demo",
    mcp_config=mcp_config,
)

await fetch_agent.run(
    "请使用网页抓取工具读取https://example.com。"
    "调用时将max_length设为1000,并返回网页正文说明的主要用途和第一个链接。"
    "只能使用本次工具返回的内容;调用失败时请明确说明,不要补写。"
)
第 2 课,共 7 课已完成 0%
←Agent是什么,它能做什么事?

讨论

登录 参与讨论

实验日志显示,MS-Agent成功连接名为fetch的Server,Qwen3-4B选择了fetch---fetch并生成以下参数:

{
  "url": "https://example.com",
  "max_length": 1000
}

工具返回网页内容后,模型据此说明该域名用于文档示例,并给出工具返回的第一个链接。检查这类结果时,应分别核对模型生成的参数、工具原始返回和最终回答。利用Qwen3-4B生成fetch工具调用参数、工具返回内容及最终回答,执行结果如下:

正文配图

直接使用魔搭MCP广场中的应用服务与自建天气MCP的区别在于,Server的实现和运行环境由魔搭托管能力负责,Notebook只需要保存连接配置并发起调用。无论使用现成服务还是自建服务,验证顺序都相同:检查服务状态、发现工具、直接测试,再让模型自主调用。

MCP权限管理

MCP 的权限管理不能只停留在“这个 Server 能不能连接”这一层,更重要的是明确三个问题:当前用户能访问哪些资源,模型能够调用哪些工具,以及每次调用会对外部系统产生什么影响。因此,权限控制应该从 Host、MCP Server 到后端业务系统逐层落实,并始终遵循最小权限原则。即使是只读工具,也不能默认认为没有风险,因为它仍然可能读取客户信息、源代码、访问令牌等敏感内容,所以需要限制可访问的目录、库表、字段和返回范围,并结合 Server 的实际实现确认是否存在额外的数据记录、缓存或外传行为。

对于会修改外部状态的操作,权限控制应随着风险逐步加强。创建文件、修改记录、发送邮件、添加日程等写入操作,最好在执行前向用户展示目标对象和关键参数,能够生成草稿或显示差异的,应优先让用户确认后再执行。同时还要避免网络超时、自动重试造成重复写入,可以通过幂等键、唯一约束或状态检查来降低风险。对于删除数据、转账、批量发送、公开发布、修改权限、执行命令和生产环境变更等高风险操作,则应默认限制自动执行,并保留明确的人工确认、二次审批和完整审计。

除了工具本身的权限,凭据和账号也需要单独控制。API Key、访问令牌等敏感信息不应出现在 Prompt、聊天记录、代码仓库或普通日志中,MCP Server 访问后端系统时应使用范围受限的专用账号和凭据,而不是直接继承过大的权限。对于敏感系统,还可以进一步把查询和修改能力拆分到不同 Server、不同账号甚至不同网络区域中。总体来说,MCP 权限管理的核心原则是:工具可以被发现,不代表就可以直接执行;一次授权也不代表以后所有操作都自动获得权限,权限应根据访问范围和操作风险逐级控制。

MCP安全风险

MCP 让模型不仅能够生成内容,还可以读取文件、查询数据库、调用网络服务,甚至修改外部系统,因此它带来的安全风险也比普通聊天模型更复杂。风险来源不仅包括用户输入,还包括网页、文档、数据库记录、工具返回结果、Server 代码以及第三方依赖。其中最典型的是 Prompt 注入:外部内容中可能隐藏恶意指令,诱导模型继续调用文件、网络或消息工具,形成危险的跨系统操作链。对此,不能只依赖模型“识别恶意提示”,而应该把所有外部内容都视为不可信数据,严格区分用户目标、系统规则和工具返回结果,并限制外部内容可以继续触发的工具范围。

另一类核心风险是越权访问和敏感信息泄漏。模型生成的参数不能被当作授权依据,Host 可以控制向模型暴露哪些工具,但 Server 仍然需要在每次调用时根据真实用户身份检查资源归属和访问权限,不能只在建立连接时验证一次。与此同时,还要控制数据在不同系统之间如何流动,只向 Server 传递完成当前任务所需的字段,对密钥、身份证号、手机号等敏感信息进行脱敏或拦截,远程连接使用 HTTPS,日志中避免保存完整凭据和敏感正文。尤其要注意,模型从一个 Server 读取到的数据,不应在没有明确授权的情况下自动发送到另一个外部 Server。

MCP 还存在恶意工具和供应链风险,因此生产环境不能只关注单次调用,而应建立完整的多层安全机制。接入 Server 前要检查来源、代码、依赖和所需权限;连接时使用受限账号、受限凭据和受控网络;工具发现后按只读、写入和高风险分类,只向模型开放真正需要的能力;执行前校验参数,对删除、发送、上传、修改权限等敏感操作要求人工确认;执行过程中限制超时、并发、返回量和网络范围;执行结束后检查工具返回内容,并保留必要的审计日志。对于正式环境,最好维护经过审核的 Server 白名单和版本清单,工具或版本发生变化后重新评估权限,并确保出现异常时能够快速停用 Server、撤销令牌和追溯操作记录。

MCP适合的场景

MCP 更适合这样的场景:外部工具和数据源比较多,希望这些能力能够被不同模型或 Agent 重复使用,同时又希望模型根据当前任务动态决定调用什么工具。 常见应用包括文件访问、数据库查询和搜索检索。例如,文件类 MCP Server 可以让模型浏览、读取和搜索项目文件,数据库类 Server 可以查询库存、订单和运营数据,搜索类 Server 则可以连接互联网、企业知识库或专业资料库。实际使用时,应尽量只开放完成任务所需的数据范围,文件访问优先采用只读方式,数据库优先使用只读账号或受控查询,并对查询范围、返回字段和结果数量进行限制;网页和搜索结果则应视为不可信输入,重要信息还需要保留来源并进行必要的交叉验证。

MCP 也很适合连接邮件、日历、网盘、项目管理系统以及企业已有的业务 API,让模型从“查询信息”进一步扩展到“完成操作”。例如,模型可以查询会议时间、整理项目进度、生成邮件草稿,也可以调用客服、物流、审批、工单和设备管理等业务能力。设计这类工具时,最好把能力拆成边界清楚的业务动作,例如分别提供“查询工单”“添加工单备注”和“关闭工单”,而不是直接给模型一个可以调用任意接口的万能工具。查询和修改也应尽量分开设置权限,对于发送邮件、修改共享权限、关闭工单、批量更新等会改变外部状态的操作,应保留必要的人工确认和审计记录。

但并不是所有接口都需要改造成 MCP。如果业务流程固定、调用关系明确、对延迟要求很高,而且根本不需要模型判断“下一步应该使用什么工具”,直接调用普通 API 往往更加简单可靠。对于删除数据、资金操作、生产环境变更等高风险任务,如果还没有完善的权限控制、人工审批、审计和回滚机制,也不应该仅仅因为 MCP 能够接入就立即实现自动化。简单来说,MCP 的价值主要体现在让模型能够灵活选择和组合多种外部能力,而固定、确定的系统调用仍然可以继续使用传统 API。

本章节所有实验数据和代码,可参考:

https://modelscope.cn/gallery/liucong/fae5791c-a024-412f-97c3-5fb93fee708e