每次与大语言模型对话时，你是否也常幻想：如果它能直接帮我查天气、从数据库提取销售报告、或调用外部API执行实际任务，那该多好？Model Context Protocol（MCP）中的Tools功能正是为解决这一痛点而设计。它为大模型提供了一套标准化的操作机制，让模型不再局限于“纸上谈兵”，而是能够真正“动手”——与外部系统交互，执行真实操作。
简单来说，MCP Tools 相当于给大模型配备了一个工具箱。每个工具都清晰标注了名称、功能和使用方法。模型能够根据对话上下文和用户意图，自主判断是否需要调用工具，无需用户逐个指令。
MCP Tools 的工作原理
MCP Tools 的核心交互模式是“模型主导”——决策权交由模型本身，它会基于上下文理解自动发现并调用工具，而非依赖用户逐句指挥。整个过程可分三步：发现、选择、调用。
第一步，发现。客户端（如集成了大模型的应用程序）先向服务器发送请求，询问：“你有哪些可用工具？”服务器返回一个工具清单，其中详细列出了每个工具的名称、功能描述及调用参数。
模型拿到清单后，就能明确自身能力范围。当用户问题确实需要外部信息或实际操作时，模型会从清单中挑选最合适的工具。这一选择完全基于对工具描述的理解及对当前任务的判断。
最后一步，调用。模型选定工具并确定参数后，客户端代表模型向服务器发送调用请求。服务器执行工具并将结果返回给客户端，客户端再将结果交给模型。模型利用这些新信息继续与用户对话或完成任务。
整个流程用消息流描述如下：
- 客户端向服务器请求工具列表。
- 服务器返回可用工具。
- 语言模型根据用户输入决定使用某个工具。
- 客户端向服务器发送工具调用请求。
- 服务器执行工具并返回结果。
- 客户端将结果交给语言模型处理。
发现可用的 Tools
要让模型知道自己有哪些可用工具，第一步是向服务器获取工具列表。这通过发送 tools/list 请求实现。最简单的请求报文如下：
{"jsonrpc": "2.0","id": 1,"method": "tools/list","params": {}}
服务器收到后返回响应，其中包含一个 tools 数组，数组每一项就是一个可用工具。例如，一个查询天气的工具的定义可能如下：
{"jsonrpc": "2.0","id": 1,"result": {"tools": [{"name": "get_weather","title": "天气信息提供器","description": "获取一个地点的当前天气信息","inputSchema": {"type": "object","properties": {"location": {"type": "string","description": "城市名称或邮政编码"}},"required": ["location"]}}],"nextCursor": null}}
在这个响应中，get_weather 工具暴露了以下关键信息：
name：工具的唯一标识，后续调用依赖它。title：对人类友好的标题，一目了然。description：工具功能的详细描述——模型主要据此理解工具用途。inputSchema：一个 JSON Schema 对象，精确规定了调用该工具所需的参数。此处说明需要location字符串。
模型正是通过 description 和 inputSchema 精准理解每个工具的功能和使用方法。
调用一个 Tool
当模型决定使用某个工具后，客户端会发送 tools/call 请求。该请求必须包含要调用的工具 name，以及符合其 inputSchema 的 arguments。
仍以查询天气为例。如果用户问“纽约天气如何？”，模型会指示客户端发出以下调用：
{"jsonrpc": "2.0","id": 2,"method": "tools/call","params": {"name": "get_weather","arguments": {"location": "New York"}}}
服务器执行 get_weather 后返回结果。一个成功的调用结果通常包含工具输出，且 isError 字段为 false。
{"jsonrpc": "2.0","id": 2,"result": {"content": [{"type": "text","text": "纽约当前天气：\n温度：22°C\n天气状况：局部多云"}],"isError": false}}
模型收到结果后，就能自然地组织出回答：“纽约现在是局部多云，温度22摄氏度。”
理解 Tool 的返回结果
Tool 的执行结果大致分为两类：非结构化内容和结构化内容。不同场景各有适用方式。
非结构化内容
非结构化内容是最常见的返回形式，它位于 result 对象的 content 字段中。content 是一个数组，可包含不同类型的数据块，例如：
text：纯文本信息，如上面的天气查询结果。image：Base64 编码的图片。audio：Base64 编码的音频。resource_link：指向其他资源的链接，如文件路径 URI。resource：直接嵌入的资源内容。
这种机制非常灵活，适合返回自然语言描述、多媒体文件或简单信息片段。
结构化内容
当场景需要精确数据且要求程序能直接处理时，应使用结构化内容。这需要 Tool 在定义时提供 outputSchema 描述输出数据结构，并在返回结果时使用 structuredContent 字段。
例如，返回更详细天气数据的工具 get_weather_data，其定义中包含了 outputSchema：
{"name": "get_weather_data","description": "获取一个地点的结构化天气数据","inputSchema": {"type": "object","properties": { "location": { "type": "string" } },"required": ["location"]},"outputSchema": {"type": "object","properties": {"temperature": { "type": "number", "description": "单位：摄氏度" },"conditions": { "type": "string" },"humidity": { "type": "number", "description": "湿度百分比" }},"required": ["temperature", "conditions", "humidity"]}}
调用该工具后，有效的返回结果会同时包含 structuredContent 和作为后备的 content：
{"jsonrpc": "2.0","id": 5,"result": {"content": [{"type": "text","text": "{\"temperature\": 22.5, \"conditions\": \"Partly cloudy\", \"humidity\": 65}"}],"structuredContent": {"temperature": 22.5,"conditions": "Partly cloudy","humidity": 65}}}
结构化返回的优势很明显：客户端应用可以直接解析、验证这些数据，无需费力处理复杂文本字符串。
下表总结了非结构化内容与结构化内容的区别：
| 特性 | 非结构化内容 | 结构化内容 |
|---|---|---|
| 承载字段 | content | structuredContent |
| 数据格式 | 包含文本、图片、音频等对象的数组 | 符合 outputSchema 的 JSON 对象 |
| 验证方式 | 无内置模式验证 | 可通过 outputSchema 进行严格验证 |
| 适用场景 | 返回自然语言描述、多媒体文件或简单文本信息 | 返回需要程序化处理的精确数据，如 API 响应体 |
错误处理与安全考量
与外部系统交互时，错误与安全问题不可避免。MCP 为 Tools 设计了两种明确的错误报告机制。
第一种是协议层面的错误。如果客户端请求不符合规范（如调用不存在的工具），服务器会返回标准的 JSON-RPC error 对象。
{"jsonrpc": "2.0","id": 3,"error": {"code": -32602,"message": "Unknown tool: invalid_tool_name"}}
第二种是工具执行过程中的错误，例如外部 API 调用失败或输入数据无效。这种错误会在 result 对象中将 isError 设为 true，并在 content 中提供错误详情。
{"jsonrpc": "2.0","id": 4,"result": {"content": [{"type": "text","text": "获取天气数据失败：API 调用频率超限"}],"isError": true}}
下表对两种错误进行了对比：
| 错误类型 | 触发场景 | 报告方式 | 示例 |
|---|---|---|---|
| 协议错误 | 客户端请求不符合协议规范 | 标准 JSON-RPC error 对象 | 调用不存在的 tool |
| 工具执行错误 | Tool 执行过程中内部失败 | 在 result 对象中设置 isError: true | 外部 API 调用失败 |
除错误处理外，安全是使用 Tool 时最受关注的一环。由于模型可能在用户未直接下达指令时调用工具，因此必须设置“人在环”的保险机制。应用程序应在模型调用工具时给出清晰视觉提示，并在执行敏感操作（如修改文件、发送邮件）前弹出确认对话框。这样才能有效防止误操作或恶意行为，确保技术始终在安全可控的范围内为人服务。
