MCP Server 能力建模：Tools、Resources、Prompts 与 Inspector 验证

上一节，咱们已经写了一个最小 MCP 案例。

在那个案例里，host.js 会创建 MCP Client，然后连接 order-mcp-server.js，最后调用 get_order 查询订单。

跑通这条链路以后，很多同学可能会自然产生一个问题，那就是：

MCP Server 到底能暴露什么能力？

如果 MCP Server 只是把几个函数注册成工具，那它和上一节的 Tool Calling 好像也没啥本质区别。

所以，这一节咱们继续往下看。

咱们来看 MCP Server 里面最常用的三类能力：

• Tools — 执行动作：让模型调用一个函数去查天气、发邮件或操作数据库
• Resources — 读取资料：让模型获取文档、图片或结构化数据
• Prompts — 可复用任务模板：说直白点就是固定的提示词方案

那么下面咱们就一个个来看。

Tools：可以执行的动作

先看第一个：Tools。

这个大家应该最好理解。

上一节的 get_order 就是一个 Tool。

Tool 表示 MCP Server 暴露出来的一个 可执行动作。

比如在售后系统里面，下面这些东西都是 Tool：

• 订单查询接口： get_order
• 判断是否满足退款条件接口：check_refund_eligibility
• 创建售后工单接口：create_ticket

这些东西都有一个共同特点：

Client 调用它以后，Server 会真正执行一段逻辑。

这个逻辑可以查数据库、调接口都行，就是一个正常的函数方法。

Resources：可以读取的资料

然后再来看 Resources。

Resource 直译过来叫做 资源

在 MCP 里面，Resource 表示为 Server 暴露出来的一份 可读取的资料。

比如 这个 URI ：refund-policy://default

这个 URI 对应的可能就是当前售后系统默认的退款规则。

Client 可以通过 MCP 协议读取这份资料。

但是大家要注意，Resource 不是直接把资料塞到大模型的上下文里面（那就成 RAG 了）

Resource 只是告诉 Host：我这里有一份资料，你可以按标准协议读取。

读不读、什么时候读、读完以后要不要交给模型，这些还是 Host 决定。

所以 Resource 的重点不是“执行动作”，而是 提供可读取内容。

Prompts：可复用的任务模板

最后一个是 Prompts。

如果按照标准方案来说，Prompt 在 MCP Server 里面的作用应该是 提供给 Host 的一套可复用任务模板

但是说白了，其实就是提示词

比如售后场景里，很多回答都要遵守同一套要求，类似于这样的提示词：

你是企业售后客服 Agent。 请根据订单查询结果、退款预检结果和售后规则回答