企业官网建设流程全解析

Spring AI MCP Server SSE 端点无响应？3 条社区验证过的修复路径

【免费下载链接】spring-aiAn Application Framework for AI Engineering项目地址: https://gitcode.com/GitHub_Trending/spr/spring-ai

服务正常启动，但浏览器或 Postman 访问localhost:8080/sse始终挂住，控制台一片安静。这里给出 3 条修复路径，按改动成本从低到高排列，第一条通常就能解决问题。

症状速判：SSE 端点挂起时先看这 4 项

先确认你的卡点是否和这里一致：

关键点在最后两项：stdio 能跑说明你的 Tool 定义和 MCP Server 核心没问题，问题只出在 HTTP 传输层；而"连得上却无响应"且零报错，是这类问题的典型指纹。

根因拆解：从版本混用看起

表层原因：新旧 artifact 混用。1.0.0-M6 时代的旧坐标spring-ai-mcp-server-webmvc-spring-boot-starter和 M7 起的spring-ai-starter-mcp-server-webmvc同时出现在依赖树里时，自动配置类和 starter 的装配预期对不上，SSE transport 的RouterFunctionBean 可能根本没被注册，但启动过程完全合法、不抛错。社区多位开发者交叉验证过这一现象，是社区反馈中命中率最高的原因。

深层原因：响应式容器与 Servlet 应用的错配。WebFlux 版 SSE transport 在源码里注册的是 WebFlux 的RouterFunctionBean（见 McpServerSseWebFluxAutoConfiguration.java），它需要 Netty 等响应式容器来承载。如果你的应用是默认的非响应式 Servlet 应用，这个 Bean 创建后没有任何容器会去拾取它——端点自然访问不到，而且全程没有异常可查。

还有一层容易漏：当前版本的McpServerProperties里protocol默认值是STREAMABLE（见 McpServerProperties.java）。SSE 传输的自动装配条件里包含protocol=SSE，不设这行，SSE 端点同样不会挂载。

修复路径：从改动最小的开始

把依赖换成 WebMVC 传输（改动最小）

如果你的应用是普通 Servlet 栈、又不想动任何启动配置，走这条。

<dependencies> <!-- ... 删除旧的 spring-ai-mcp-server-*-starter 坐标 --> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId> </dependency> </dependencies>

spring: ai: mcp: server: protocol: SSE # 必须显式指定，默认是 STREAMABLE

重启后访问/sse，应立刻看到event: endpoint，其 data 是消息回传地址（默认/mcp/message）。代价：这条路径把 SSE 传输绑定在 Servlet 栈上，如果你的工程未来要整体切响应式，届时需要重新选择。

若执行上一步后仍然无响应，切换到下一条路径 →

用 WebFlux 并真正启用响应式容器

如果你就是想在响应式栈上跑 SSE，依赖必须只留 webflux，并且把整个应用切到响应式：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-mcp-server-webflux</artifactId> </dependency>

spring: main: web-application-type: reactive ai: mcp: server: protocol: SSE type: ASYNC

web-application-type: reactive这一行是社区反馈里最容易漏的：它让 Spring Boot 用 Netty 而非 Servlet 容器启动，WebFlux 版RouterFunction才会真正被挂载。验证方法同上，/sse应立即推送event: endpoint。代价：整个应用进入响应式环境，OpenFeign 客户端在此模式下不可用，Spring Cloud Gateway 的转发链路也要重新评估。

若上面两条都通了但你发现 MCP 客户端侧也在迁移，考虑第三条路径 →

顺势迁到 Streamable HTTP 传输

当前代码里 SSE transport 已被标注@Deprecated(since = "2.0.0", forRemoval = true)（见上文两个自动配置类的注解），而 Streamable HTTP 是默认协议。社区多位开发者反馈，MCP 规范本身也把旧的 SSE 传输标记为 deprecated，Streamable HTTP 是长期方向。

如果客户端版本允许，直接删掉protocol配置项，依赖保持spring-ai-starter-mcp-server-webmvc，按 Streamable HTTP 端点验证：向默认端点发initialize请求，应返回协议协商响应。代价：这是协议升级而非配置修复，所有 MCP 客户端必须同步支持，老客户端会全部失联，需要灰度切换。

踩坑清单

• ❌ M6 旧坐标和 M7 新坐标混用 → 自动配置与 starter 对不上，SSE 端点静默缺失
• ❌ 忘了显式设置spring.ai.mcp.server.protocol: SSE→ 默认走 STREAMABLE，SSE 条件装配直接不生效
• ❌ 同时引入 webmvc 和 webflux 两个 MCP Server starter → 两个自动配置都满足条件，由加载顺序决定谁生效，行为不可预期
• ❌ 切了web-application-type: reactive后还依赖 OpenFeign → 客户端在响应式栈下无法工作，调用直接失败
• ❌ 用 Postman 普通 GET 测/sse就判定"没数据" → SSE 是长连接流，工具侧要开启事件流解析才能看到推送内容

收尾

当前版本下最省事的组合：Servlet 应用 +spring-ai-starter-mcp-server-webmvc+ 显式protocol: SSE。考虑到源码里 SSE transport 已标记移除、官方默认切向 Streamable HTTP，建议客户端允许时尽早迁移，届时旧路径自然退役。

【免费下载链接】spring-aiAn Application Framework for AI Engineering项目地址: https://gitcode.com/GitHub_Trending/spr/spring-ai