@MPietrala I’m still in the process of wrapping my head around this
Do you think it makes sense to separate it into a library and a server component such that the library could be used by Gramps Web API directly? How would such an architecture look like? I’d be happy to contribute to make this work.
Another question, I see you are relying on Gramps QL. Actually @dsblank created an alternative, Object QL, which is probably much faster. Were you aware of that? It kind of killed my motivation to improve on Gramps QL
Little background on me, I’m a Product Manager as profession , so good at figuring out what needs to be implemented, but not a developer and can definitely use some support there.
What you are suggesting here, is it to move all the tool calls logic (grouping of different api calls + format handlers) into gramps web api library? They themselves become api calls so that they can be done either by the internal tools and the external mcp. Do I understand that correctly?
That sound good, and would get rid of a lot of duplicated work that I created. It would also give us the ability to constrain a bit the type checking better as now i basically had to copy everything there. And then you can use the work I did to improve the internal chat bots.
My overall goal of this project was to build an agent that could automate the research and documentation, and I have some other projects that I am experimenting with that would use this. The mcp to connect to Gramps was the first step in this.
I rely on it, since your API relies on it, not fixed to any. We just need to give the LLM the documentation.
