MCP服务混合部署实战：工具、资源与提示词整合到一个服务

引言

在MCP（Model Context Protocol）的实际开发中，很多开发者会有一个疑问：工具（Tool）、提示词（Prompt）和资源（Resource）是否必须分开部署？每个服务是否只能提供单一类型的能力？本文通过一个实战演示，解答这个常见困惑——一个MCP服务可以同时提供多个工具、多个提示词和多个资源。

MCP协议简介

MCP（Model Context Protocol）是由Anthropic于2024年底推出的开放协议，旨在标准化大语言模型与外部数据源、工具之间的交互方式。它类似于Web开发中的REST API规范，但专门为AI应用场景设计。MCP采用客户端-服务器架构，其中MCP服务器暴露能力（工具、提示词、资源），MCP客户端（通常嵌入在AI应用中）负责发现和调用这些能力。协议基于JSON-RPC 2.0通信，支持stdio和HTTP+SSE两种传输方式，使得本地和远程部署都成为可能。理解这一协议背景，有助于我们更好地把握本文讨论的服务组织方式问题。

从分离到整合：MCP服务的组织方式

单一职责只是学习阶段的起点

在之前的学习过程中，为了便于理解，我们通常将工具、提示词模板和资源分开编写和测试。例如：

• 单独编写一个工具服务（如代码生成工具）
• 单独编写一个提示词模板服务
• 单独编写一个资源服务

这种分离式的写法有助于学习和调试，但很多开发者因此产生了一个误解：以为在生产环境中也必须这样分开部署。

理解三大核心原语的技术定位

在深入讨论混合部署之前，有必要明确MCP协议中三大核心原语的技术区分：工具（Tool）是模型可以主动调用的函数，类似于OpenAI的Function Calling机制，模型根据用户意图决定是否调用；提示词（Prompt）是预定义的模板，用于标准化特定场景下的交互模式，客户端可以将其展示为斜杠命令或快捷操作；资源（Resource）则类似于REST API中的GET端点，提供只读数据供模型参考，如文件内容、数据库记录等。三者的控制权不同——工具由模型决定调用，提示词由用户触发，资源由应用程序控制。正因为它们在协议层面是平等的能力声明，所以天然支持在同一服务中共存。

混合部署才是生产环境的常态

实际上，MCP协议的设计允许一个服务同时注册和暴露多种类型的能力。在演示中，我们创建了一个名为 service 的综合服务，将以下内容整合到同一个MCP服务中：

• 多个工具：比如「打招呼」和「说再见」两个工具方法
• 多个提示词模板：预定义的Prompt模板
• 多个资源：供模型调用的外部数据资源

这意味着你可以根据业务需求，自由组织你的MCP服务结构，而不必受限于「一个服务只做一件事」的思维定式。

这一讨论实际上映射了软件工程中经典的微服务vs单体架构之争。微服务架构强调每个服务只负责单一功能，便于独立部署和扩展，但带来了服务间通信、分布式事务等复杂性。在MCP场景中，过度拆分意味着需要管理多个服务进程、多份配置文件，增加了运维负担。而将相关能力整合到一个MCP服务中，减少了进程间通信开销，简化了部署流程，特别适合功能内聚度高的业务场景。当然，对于大型系统，按领域边界拆分MCP服务仍然是合理的选择——关键在于根据实际需求做出权衡，而非教条式地遵循某种模式。

实战演示：MCP综合服务的搭建与验证

服务注册与启动流程

在代码层面，整合的过程非常直观：

1. 将之前分别编写的工具定义、提示词模板和资源声明，统一放到一个服务文件中
2. 在MCP服务启动时，同时注册所有的工具、提示词和资源
3. 启动服务后，客户端可以一次性发现并调用所有能力

从协议层面来看，MCP客户端在连接服务器后会通过 initialize 握手获取服务器的能力声明（Capabilities），然后分别通过 tools/list、prompts/list、resources/list 等方法发现所有已注册的能力。这些发现机制是并行独立的，服务器只需在初始化时将所有能力注册到对应的处理器中即可。

验证混合部署的结果

服务启动后，通过MCP客户端连接可以看到：

• 工具列表中同时出现了「打招呼」和「说再见」等多个方法
• 提示词模板正常加载，可以被客户端获取和使用
• 资源同样可被正常访问

所有能力在同一个服务实例中共存，互不干扰，客户端可以按需调用任意一种。

MCP提示词和资源模板的定位说明

值得一提的是，在MCP的三大核心能力中，提示词（Prompt）和资源模板（Resource Template）相对简单，基本的用法已经能够满足大多数场景需求。它们的API设计直观，学习成本较低。

真正需要深入研究的是**工具（Tool）**部分。工具是MCP协议中功能最强大、也最复杂的组件，它涉及到：

• 工具的定义与参数描述（基于JSON Schema的输入参数校验）
• 工具与大模型的交互机制（模型如何理解工具描述并决定调用时机）
• 工具调用的安全性和权限控制
• 工具与提示词、资源的协同使用

在安全性方面，MCP协议采用了人机协同（Human-in-the-Loop）的设计理念。当模型决定调用某个工具时，客户端应用可以在执行前向用户展示确认对话框，让用户审批工具调用的参数和意图。此外，MCP服务器可以通过能力声明（Capabilities）来限制暴露的功能范围，客户端也可以实施访问控制策略。这种多层安全机制确保了即使模型产生了不当的工具调用请求，也不会直接造成安全风险。这也是工具部分复杂度远高于提示词和资源的重要原因之一。

后续的学习重点也将放在工具的高级用法上，包括如何结合提示词和资源来构建更强大的AI应用。

核心启示：MCP服务架构的灵活性

对于MCP开发者来说，这个演示传递了一个重要信息：不要被学习阶段的代码组织方式所束缚。在实际项目中：

• 你可以将相关的工具、提示词和资源打包到同一个服务中
• 一个MCP服务可以同时暴露多种能力
• 服务的组织方式应该根据业务逻辑来决定，而非技术限制

这种灵活性正是MCP协议设计的优势所在，它让开发者能够以最合理的方式组织自己的AI服务架构。无论是选择将所有能力集中在一个服务中以简化部署，还是按照领域边界拆分为多个专注的服务以便于团队协作和独立扩展，MCP协议都提供了充分的支持。最终的架构决策应该基于团队规模、业务复杂度、部署环境等实际因素，而非对协议能力的误解。

核心要点

• 一个MCP服务可以同时提供多个工具、多个提示词和多个资源，无需分开部署
• 生产环境中应根据业务逻辑自由组织MCP服务结构，而非受限于单一职责的学习模式
• 提示词和资源模板相对简单，工具（Tool）才是MCP协议中最核心、最需要深入学习的部分
• MCP协议的灵活性允许开发者以最合理的方式组织AI服务架构
• MCP三大原语的控制权各不相同：工具由模型触发、提示词由用户触发、资源由应用程序控制
• 工具调用的安全性通过人机协同机制和多层访问控制来保障