Positioning and When to Use

这一页只回答一个问题：什么时候该进入 MCP，而不是继续停留在本地 Tool、Skill，或者直接手写第三方 SDK 调用。

在 AI4J 里，这个判断不是抽象架构偏好，而是会直接决定：

• 请求链是不是还能保持干净
• 多服务能力是否可治理
• 错误和权限是否还能被追踪
• 后续是否能发布成标准 MCP server

1. MCP 在 AI4J 里的定位不是“另一种 Tool”

从实现看，MCP 至少同时覆盖了四类职责：

• McpTransport：决定连接模型和会话形态
• McpClient：负责单服务握手、缓存、断连与重连
• McpGateway：负责多服务目录与调用路由
• ToolUtil：负责把 MCP 服务白名单投影成 provider tools

所以它真正的位置是：

• 协议层
• 服务接入层
• 多服务编组层

不是“本地方法多了个远程版本”。

2. 什么时候本地 Tool 就够了

以下场景通常不需要 MCP：

1. 能力就在当前 JVM 里
2. 不需要独立连接或外部进程生命周期
3. 输入输出可以稳定地用 Java 类型直接建模
4. 模型不需要通过协议去发现、列举或消费这组能力

典型例子：

• 文本转换
• 本地文件解析
• 纯业务函数
• 少量内建工具

这时直接用本地 Tool 更简单，也更容易调试。

3. 什么时候 Skill 才是正确答案

如果你真正想解决的是：

• 教模型一套执行方法
• 复用规范、模板、SOP
• 提供提示词和操作约定

那是 Skill 的职责。

一句话区分：

• Skill 解决“模型应该怎么做”
• Tool / MCP 解决“模型实际上能调用什么能力”

把这两者混起来，通常会导致两种坏结果：

• 本该是文档和方法论的问题，被错误地做成服务协议
• 本该是协议和权限的问题，被错误地塞进 prompt 描述

4. 哪些信号说明已经该用 MCP

出现下面这些信号时，就不应该继续把它当成本地 tool 问题：

• 需要连接第三方系统或内部平台
• 服务有独立进程、独立端口或独立部署形态
• 未来会接不止一个能力源
• 希望能力通过标准 MCP 协议暴露给其他宿主
• 除了动作外，还想提供 resources 或 prompts

从 AI4J 的运行时角度看，只要问题开始跨：

• 进程
• 服务
• 系统

优先就该想 MCP。

5. 为什么“直接包一层 SDK 调用”不等于 MCP

很多人会把第三方 API 临时包进一个本地 tool，然后觉得“也能用”。短期确实能跑，但会失去 MCP 提供的几个正式边界：

• transport 类型显式化
• 外部服务独立生命周期
• 请求级 mcpServices 白名单
• 多服务统一目录与调用路由
• tool / resource / prompt 三类能力分层

也就是说，直接包一层 SDK 调用，本质上只是“远端逻辑本地代理”；它没有建立独立的协议接入面。

6. AI4J 当前实现给出的决策信号

下面几个实现锚点非常说明问题：

• ChatCompletion.mcpServices
• ResponseRequest.mcpServices
• ToolUtil.getAllTools(functions, mcpServices)
• McpGateway.getAvailableTools(...)
• McpClient.initialize()

它们共同说明：

1. MCP 服务不是默认全开
2. MCP 能力不是 provider 原生概念，而是先在本地运行时被投影
3. 服务层治理和请求层暴露是分开的

如果你的需求不需要这些层，那多半不需要 MCP。

7. 一个实用决策表

需求	更适合什么
把本地 Java 方法暴露给模型	Tool
给模型一套工作流说明或模板	Skill
连接外部系统并保留独立服务边界	MCP
一个宿主里统一管理多个外部能力服务	MCP
需要发布自己的 Java 能力给别的客户端消费	MCP
只是告诉模型“先检索，再总结”	Skill

8. 什么时候“不该”急着进入 MCP

下面这些情况，如果直接上 MCP，通常是过度设计：

• 只有一个简单本地函数
• 不存在独立部署或跨进程边界
• 不需要服务目录或动态发现
• 只是在写 demo，不打算保留长期接入层

MCP 是能力接入协议，不是所有自动化任务都必须套一层协议。

9. 需要特别警惕的误判

把 Skill 写成 MCP

如果没有独立服务、没有连接生命周期、没有标准能力目录，只是一些模板和规范，那不是 MCP。

把远端 API 硬塞成本地 Tool

短期实现更快，但之后你会丢掉服务边界、连接状态和多服务治理。

把 MCP 当成“天然隔离”

当前远端全局工具在 McpGatewayToolRegistry 中按 toolName -> clientId 建映射；如果不同服务暴露同名工具，存在覆盖风险。是否使用 MCP，不只要看“能不能连”，还要看你是否愿意接受当前实现的命名与路由约束。

10. 这一页的结论

在 AI4J 里，MCP 适用于“外部能力作为独立服务接入”的问题，不适用于所有工具化问题。只要你开始关心 transport、服务生命周期、多服务编组、请求级白名单，或者要把 Java 能力正式发布给别的客户端，MCP 就是正确入口。