一行代码不用改！搞定 HSF 转 MCP Server

• MCP 自身演进非常快，内部用户非常难跟上其迭代节奏。0326的 SPEC 距离上次发布只过了 4 个月，根据 MCP 2025 的 RoadMap，未来可能还会有 3 次以上的 SPEC 发布，这些 SPEC 不保证协议层面完全前向兼容。很容易遇到现在接入了官方开源的 SDK，后面还需要处理线上的老版本 MCP 如何升级到最新版本的重复投入和稳定性成本问题，对集团内核心应用的研发而言会非常痛苦。

• 现有 MCP 的 SDK 还比较初级，仅对 SPEC 做了简单实现，在可用性上远远达不到生产级别，需要较长的时间稳定。比如 java-sdk 的 0.7.0 和 0.8.0 的 API 有非常多的改动项，MCP Java SDK Migration Guide: 0.7.0 to 0.8.0。对于应用开发同学而言，不光要升级，还要改接入的代码，成本和风险都是翻倍的。

• MCP 生态虽然热火朝天，但缺乏系统化和最优实践，达到共识的时间成本和个人的学习成本不可忽视。如何快速掌握 MCP 协议和 MCP 应用开发，最快的方式当然是在现有的业务场景里先跑起来，然后一边运行一边学习。那么如何才能在不懂 MCP 的前提下跑起来自己的 MCP Server ？

step1 ：打开对应环境的 HSFOPS 后台，选择 MCP 侧边栏

step2：选择需要转 MCP Tool 的 hsf 应用（自己为 owner/ops 的应用）、服务名和方法名。

注意：工具描述需要准确具体，用于给大模型识别 tool 的用途。

step3：补充标记为 //TODO 部分的 method 的入参的 fieldName 和 description

请求参数结构会自动生成，只需添加名称(key) 和描述 (description)。

step4：利用上述工具以 mcp sse 方式访问域名( tool 创建完后一分钟左右即可被 list )

http://{MCP endpoint prefix}/{applicationName}/sse

cursor 配置如下

{  "mcpServers": {    "{applicationName}": {      "url": "http://{MCP endpoint prefix}/{applicationName}/sse"    }  }}

cursor

• MCP 不是银弹。从分布式领域和 AI 基础设施的角度看，MCP 作为一个通信协议或 AI 智能体协议都不够成熟，远达不到生产级别落地的标准。因此，无论是业务还是基础设施团队，盲目的选择 All in MCP 是不负责任的表现。通过快速跟进，快速试错实现 AI 业务场景的原型落地是更好的选择。因此，AI infra 团队关注的重点应是如何降低业务创新的成本，而不是拉上业务一起为自己的错误决策埋单。将这一点落实到技术决策，选择由 Higress 网关承担 MCP 协议卸载，再适配内部已有协议是对阿里内部全局较优的选择。无论是 MCP 发展到足够成熟还是被其他的生态取代，业务都可以灵活的选择跟进或切换，整个公司的基础设施不会发生 vendor lock-in 。
• Market 重要吗？重要也不重要。AI 智能体解决的是如何扩展 LLMs 的边界，从而解决更复杂的实际问题。MCP 合理的定位是解决 MxN 的重复建设和标准化资源访问的问题，MCP Market 是一个自然而然的产品，其存在是有必要性的。但认为掌握了 Market 就掌握了一切，这是本末倒置的想法。合理的路径是基础设施适配先做到位，让业务研发同学能够有更多的选择权，更快的迭代速度，自然会有完善易用的 Market 作为门户存在。前面的积累如果没有做扎实，后者只能是空中楼阁。
• 看起来只关注了 Tool 的转换， Prompts/Roots 和 Sampling 呢？回答这个问题需要扩展阅读一下 MCP 的诞生背景以及使用场景，包括 Anthropic 对其的定位和创建 MCP 的目标。MCP 是 AI 业务工程化的起点里程碑，但不是终点，在投入 MCP 的同时关注 A2A 和 ANP 这些 AI Agent 交互协议的发展是做 Infra 的团队的必然选择。

本文提供了阿里内部大规模 HSF 服务快速转换为 MCP Server 的实践，用于帮助业务同学降低改造成本，快速融入 MCP 生态，紧跟 AI 原生应用的发展速度。目前看来，MCP 只是第一步，AI 原生应用的路还很长，希望这篇文章能对 AI Infra 领域感兴趣的同学和团队有所启发。