bengbengbalabalabeng commented on issue #613: URL: https://github.com/apache/fesod/issues/613#issuecomment-3426883128
> Thanks for your following. Feel good to meet such proposal in community. > > I haven't conducted research on popular MCP implementations yet; this discussion is based solely on my current personal observations. > > 1. The primary responsibility of the Request Router is likely request distribution—routing requests to the corresponding Tool implementation methods. It can perform basic rule validation and centralize exception handling. Functions like load balancing, retries, and circuit breakers can be delegated to external controllers. > 2. Whether to expose metrics depends on implementation and practical value. Single, one-off executions may not warrant metric introduction, but they become more useful in scenarios with scaled, repeated calls. Basic metrics like execution duration, resource consumption, and throughput can be implemented at the finest granularity. Alternatively, observability can be exposed simply by launching agents. > 3. A quick glance at the accompanying code repository suggests it might be a bit heavy? While leveraging SpringAI offers efficiency benefits, introducing SpringCache while also manually setting cache via utility methods seems somewhat at odds with the JSR107 philosophy. Additionally, could Fesod's unique strengths be leveraged more? For instance, efficient reading of massive datasets? Otherwise, if only basic functionality is provided, POI agents might be more mature. Also, consider implementing unit tests—such as using Fesod for logic and cross-validating with POI. > > 我还没有针对流行的MCP实现做调查，仅凭个人当前感觉进行讨论 > > 1. Request Router的职责可能主要负责分发请求，既将请求路由给对应的Tool实现方法，可以做一些简单的规则校验，可以统一异常管理；负载均衡、重试、熔断等可以交给外部控制。 > 2. 暴露指标是否重取决于实现的方式以及是否有意义，单一的单次的执行可能没有太大的引入指标的必要性，在成规模多次数调用的场景下可能更有用。最小粒度可以尝试实现执行时长、资源消耗、吞吐量等基本指标，也可以简单地通过agent等启动的方式仅暴露可观测性； > 3. 简单看了下附带的代码仓库，有点重？基于SpringAI的好处自然是实现的效率，但是，诸如引入SpringCache的同时又采取手动Util Set Cache的方案是否不太适配JSR107的思路？同时，还可以更多发挥Fesod本身的特色？譬如高效读取海量数据？否则仅提供基本功能的话，POI的agent可能更成熟？同时，可以考虑实现一些单元测试，譬如采用Fesod实现逻辑，通过POI交叉验证等； Thank you for the detailed feedback and suggestions 🤝. Looking back at the `fastexcel-server` MCP implementation, I agree with your point that while Spring AI brings convenience, it also introduces some “heaviness,” such as including SpringCache without fully leveraging it. I also reviewed the documentation of Spring AI and the Model Context Protocol (MCP) today, and found that the [MCP SDK for Java](https://github.com/modelcontextprotocol/java-sdk) already provides JSON-RPC support (including the Request Router) in its `mcp-core` module. Since this SDK is maintained by the Spring team itself, it seems feasible to replace the heavier Spring ecosystem dependencies with the MCP SDK directly, making the implementation lighter and more aligned with MCP’s design philosophy. Moving forward, I also plan to explore leveraging Fesod’s strengths in efficiently handling massive datasets to build a more distinctive implementation. Feedback and suggestions for improvements are very welcome. --- 感谢你的详细反馈和建议 🤝。回看 `fastexcel-server` MCP 的实现，确实在享受 Spring AI 带来便利的同时，也存在一些“偏重”的问题，例如引入了 SpringCache 却没有真正发挥其作用。对此我非常认同你的观点。 我今天也查阅了 Spring AI 以及 Model Context Protocol (MCP) 的相关资料，发现 [MCP SDK for Java](https://github.com/modelcontextprotocol/java-sdk) 中的 `mcp-core` 模块已经默认实现了 JSON-RPC（包括 Request Router），而且这个 SDK 是由 Spring 内部团队维护的。因此，完全可以考虑直接使用 MCP SDK 来替代 Spring 的“重”生态依赖，从而让实现更加轻量化，也更贴合 MCP 的设计初衷。 后续我也会尝试结合 Fesod 在高效读取海量数据方面的优势，探索更有特色的实现方式。 欢迎提出优化意见或改进建议。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
