[Enhancement] Implement a Model Context Protocol (MCP) based agent for Fesod

[alaahong]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

We would like to build an MCP (Model Context Protocol) based agent around Fesod so that its high‑performance spreadsheet (Excel) processing capabilities can be exposed as structured tools via an MCP server. This enables AI / LLM agents to perform spreadsheet analysis, automated data completion, querying, difference comparison, and workflow automation.

Solution

1. Design and implement an MCP server adapter for Fesod supporting JSON-RPC over stdio (and optionally WebSocket/HTTP).
2. Register typical spreadsheet operation tools, e.g. list_sheets, read_sheet_range, analyze, update, diff, export, etc.
3. Support resource handles (workbook resourceId) to avoid repeated file loading.
4. Return structured JSON outputs optimized for LLM / agent consumption, including truncation indicators and metadata.
5. (Optional) Provide a declarative transform_pipeline tool for multi-step data processing (read → filter → derive → aggregate → export).
6. Establish unified error codes and JSON Schemas for tool inputs/outputs for better LLM alignment.
7. Introduce caching (LRU) and range limiting for performance and safety.

Alternatives

1. Expose only a REST API wrapper around Fesod (less portable for emerging agent runtimes).
2. Provide only language-specific SDKs (Java/Python), which increases integration friction for heterogeneous AI toolchains.

Anything else?

Recommend starting from a minimal viable set: open_workbook, list_sheets, read_sheet_range, analyze, then iteratively add query, diff, update, export, and finally transform_pipeline.

Are you willing to submit a PR?

• I'm willing to submit a PR!

[alaahong]

Draft flow

+-----------------+         JSON-RPC (stdio / WS / HTTP)         +------------------------+
|  LLM / Agent    | <--------------------------------------------> |  MCP Server (Java)     |
|  (OpenAI, etc.) |                                             |  - Request Router       |
+-----------------+                                             |  - Tool Registry        |
                                                                |  - Resource Manager     |
                                                                |  - Workbook Cache (LRU) |
                                                                |  - Pipeline Executor    |
                                                                |  - Metrics & Logging    |
                                                                +------------+------------+
                                                                             |
                                                                       +-----v------+
                                                                       |  Fesod API |
                                                                       +------------+
                                                                             |
                                                                         File System

[bengbengbalabalabeng]

你好 @alaahong ，
我在阅读 Draft flow 时有几个细化的问题想请教：

1. Request Router 在设计中具体承担哪些职责？它是仅做请求分发，还是也会包含负载均衡、错误重试等逻辑？
2. 关于 Metrics

• 计划暴露哪些关键指标（例如请求延迟、错误率、缓存命中率、工具调用次数等）？
• 暴露指标是否会让 MCP server 本身变得更“重”？
• 这些指标会暴露给哪些系统？

另外，我之前在调研 fast-excel 时写过一个基于 MCP 的 demo，简单实现了 list_sheets、read_sheet_range、cache 等工具（cache 使用的是 Caffeine 实现）。
👉 代码仓库 👉 Deepwiki

欢迎提出优化意见或改进建议 🤝 🤝 🤝。

---

Hi @alaahong ,
While reviewing the Draft flow, I had a few detailed questions:

1. For the Request Router, what are its specific responsibilities? Will it only handle request dispatching, or also include load balancing, retries, and error routing?
2. Regarding Metrics

• which key indicators are planned to be exposed (e.g., request latency, error rate, cache hit ratio, tool invocation counts)?
• Will exposing metrics make the MCP server itself “heavier”?
• To whom will these metrics be exposed?

In addition, when I was exploring fast-excel earlier, I created a small MCP demo that implements tools like list_sheets, read_sheet_range, and cache (with Caffeine).
👉 code 👉 Deepwiki

Feedback and suggestions for improvements are very welcome 🤝 🤝 🤝.

[alaahong]

你好 @alaahong ， 我在阅读 Draft flow 时有几个细化的问题想请教：

1. Request Router 在设计中具体承担哪些职责？它是仅做请求分发，还是也会包含负载均衡、错误重试等逻辑？
2. 关于 Metrics

• 计划暴露哪些关键指标（例如请求延迟、错误率、缓存命中率、工具调用次数等）？
• 暴露指标是否会让 MCP server 本身变得更“重”？
• 这些指标会暴露给哪些系统？

另外，我之前在调研 fast-excel 时写过一个基于 MCP 的 demo，简单实现了 list_sheets、read_sheet_range、cache 等工具（cache 使用的是 Caffeine 实现）。 👉 代码仓库 👉 Deepwiki

欢迎提出优化意见或改进建议 🤝 🤝 🤝。

Hi @alaahong , While reviewing the Draft flow, I had a few detailed questions:

1. For the Request Router, what are its specific responsibilities? Will it only handle request dispatching, or also include load balancing, retries, and error routing?
2. Regarding Metrics

• which key indicators are planned to be exposed (e.g., request latency, error rate, cache hit ratio, tool invocation counts)?
• Will exposing metrics make the MCP server itself “heavier”?
• To whom will these metrics be exposed?

In addition, when I was exploring fast-excel earlier, I created a small MCP demo that implements tools like list_sheets, read_sheet_range, and cache (with Caffeine). 👉 code 👉 Deepwiki

Feedback and suggestions for improvements are very welcome 🤝 🤝 🤝.

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交叉验证等；

[bengbengbalabalabeng]

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 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 中的 mcp-core 模块已经默认实现了 JSON-RPC（包括 Request Router），而且这个 SDK 是由 Spring 内部团队维护的。因此，完全可以考虑直接使用 MCP SDK 来替代 Spring 的“重”生态依赖，从而让实现更加轻量化，也更贴合 MCP 的设计初衷。

后续我也会尝试结合 Fesod 在高效读取海量数据方面的优势，探索更有特色的实现方式。
欢迎提出优化意见或改进建议。