Hi, the ability to enable older IoTDB versions definitely is a good point. Also considering that the DataNode has no plugin-mechanism, adding more to the DataNode sounds sub-ideal. Still I usually use IoTDB in a standalone mode, where I run DataNode and ConfigNode in the same JVM, there having the MCP within the DataNode would have the benefit of not requiring another system.
I think I’ll play around with this and thanks for the expanation. Chris Von: Wang Critas <cri...@outlook.com> Datum: Freitag, 11. Juli 2025 um 06:19 An: dev@iotdb.apache.org <dev@iotdb.apache.org> Betreff: 答复: Why is the MCP server not part of the DataNode? Hi Chris, thanks for your feedback! We intentionally designed iotdb-mcp-server as a standalone module for flexibility: * Version Independence: Decoupling from DataNode allows users to adopt MCP without tying to specific IoTDB releases, simplifying upgrades. * Selective Deployment: Users can deploy the MCP proxy only when needed, avoiding unnecessary overhead on DataNode. * Protocol Agility: Isolating the protocol adapter enables faster iteration (e.g., future MCP enhancements). Performance concerns can be addressed via connection pooling, but decoupling offers greater deployment versatility. Best regards Xuan Wang 发件人: Christofer Dutz <christofer.d...@c-ware.de> 日期: 星期四, 2025年7月10日 00:33 收件人: dev@iotdb.apache.org <dev@iotdb.apache.org> 主题: Why is the MCP server not part of the DataNode? Hi all, today I took the liberty to have a look at the new mcp server and was quite surprized to see it just being 3 files of python. Haiving a deeper look at it, it seems to be a rather trivial server component, that simply translates MCP requests to Session API requests. First of all … is it worth maintaining another repo for this? This way it requires a separate vote and release process, if we want ot release it. Also do I think that integrating an MCP server to the DataNode should be a lot more performant, than having a proxy server in between. I know the fastMCP tool isn’t available, however I don’t think that the MCP protocol is particularly complex. At least it doesn’t look as if we’re using any oft he higher level features in the current MCP server. Wouldn’t this just be 3 or 4 rest endpoints to consume JSON? Chris
