To clarify, it appears Victor's queries around MCP isn't about replacing Postgre. Instead, it's about providing robust, documented API connectivity – a need that directly aligns my desire for improved 'self-service' capabilities. MCP's abstract database complexities present data in an LLM-digestible format leveraging APIs. (The same fundamental requirement by dozens of others); Accessible, user-friendly API interfaces, not raw backend exposure.
>From a business standpoint, the current state of documentation significantly hinders Fineract's potential for wider adoption and organic growth beyond the immediate community. Enabling wider adoption can rapidly amplify Fineract's functionality and innovation, while allowing the core community to maintain its focus on stability and accessibility. Legacy systems, whether open or closed source struggle with the challenge on innovation versus technical deficiencies. It's difficult, complex and requires intent plus a lot of cooperation to cure. While I don't possess coding skills, I deeply admire those who can efficiently resolve technical issues. Adam and others have been crushing issues. The 'theory nerd' in me ponders the value added if accumulated efforts are strategically focused. I strongly encourage formulating process to accept and prioritize work, grounded in a mutually agreed and understood product vision. I see "how" discussion is ongoing on the topic. Consider a simple framework for leveraging product vision in prioritization: 1. *Establish and Communicate a Clear Product Vision:* Ensure the vision is well-defined, accepted, and understood by all contributors. 2. *Implement a Standardized Decision-Making Process:* Develop a simple, consistent method to evaluate product suggestions, yielding a clear 'yes' or 'no' accepting work based on alignment with the vision. 3. *Define Effort Allocation Targets:* Leadership / community should agree on percentage-based goals for addressing technical debt (ensuring existing stable functionality, relevance, and documentation) versus pursuing innovation. 4. *Define Innovation:* Innovation should be carefully defined. Conversely, investing in a stable, bug-free, and well-documented core will empower external contributions, accelerating genuine, agile innovation. *In essence, by prioritizing API accessibility, curing documentation gaps, and adhering to a clear product vision, Fineract can achieve both stability and accelerated growth through increased contributions.* Regards On Fri, Mar 28, 2025 at 1:37 AM Naphlin Peter <starna...@gmail.com> wrote: > Hi Victor, > > I have read the write up you have shared on Apache Doris, how would this > be different from for example using a generic postgres or mysql MCP server > that are already available and open? > > Regards, > > Naphlin Peter Akena, > Kampala, > Uganda > > tel:+256777110054 > skype: *napho.peter* > > > On Thu, Mar 27, 2025 at 11: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 >> > -- -- Paul
