+1 for documenting the APIs properly and improvements to context mapping. By context, I mean that the APis should have notations such that one can see how they are to be used and what logic sits behind them.
+0 (neutral) to adopting a specific vendor implementation - except as a proof of concept. I think we don't know if this specific MCP server concept will survive a year, and I'd want to be able to "cut away" from it. i.e. I think we all know that building new dependencies on new tech can be risky or if you are lucky, "brilliant in the rear view mirror". Victor - does this require or prefer a separate GitHub repo for the "server"? Where would it sit in the project? On Fri, Mar 28, 2025 at 5:25 AM Kristof Jozsa <kristof.jo...@gmail.com> wrote: > Hi Victor, > > I'd be very interested to have a look at what you've done so far, or even > help in - I wrote several MCP servers myself in the past month. I think > having an up-to-date MCP server for Fineract could easily open new > possibilities and new scenarios, and well worth our efforts.. > > Best, > Kristof > > > > On Thu, Mar 27, 2025 at 9:02 PM VICTOR MANUEL ROMERO RODRIGUEZ < > victor.rom...@fintecheando.mx> wrote: > >> Hello Apache Fineract Community, >> >> Question: >> >> Is there any interest in the Apache Fineract Community to integrate a MCP >> Server ? >> >> There are other Apache Projects that are integrating this feature, i.e >> Apache Doris. >> >> https://www.linkedin.com/pulse/apache-doris-mcp-server-mingyu-chen-4k95c/ >> >> We have already made it por specific use cases like KCY and Loan >> origination. >> >> But it could be useful if all the Apache Fineract APIs could be mapped. >> >> The MCP implementation tasks could be easier if we could have OpenApi >> (swagger) updated and well documented and maybe this is the first step for >> the MCP tool. >> >> I will be glad to hear your thoughts on this matter. >> >> Regards >> >> Victor Romero >> >
