Hi all,
I’d been using cabout-me/gramps-mcp for a while - credit where it’s due, without it I probably wouldn’t have started this at all. I kept running into a few methods it didn’t cover, though, and it doesn’t look actively maintained anymore, so I decided to write my own, based on it but on a different stack: Rust instead of Python: gramps-web-mcp-rs.
Differences so far: a smaller Docker image, and a larger set of tools: it covers the full Gramps Web API surface I could find (search, get, create, update, delete, merge across all object types: people, families, events, places, sources, citations, media, repositories, etc.), with test coverage.
Like the original, I see this as an MCP server and use it that way - standalone, so it can be combined with other MCPs (web search, filesystem, etc.) in the same agent, rather than living inside an internal chatbot.
On GQL: I experimented with adding it (it’s sitting in a branch), but didn’t include it in the release because results weren’t good enough. I didn’t manage to get an LLM to reliably write correct GQL syntax from a natural-language question; it burned a lot of tokens on retries and still got the syntax wrong often enough that I wouldn’t ship it as-is.
It also has a read-only mode that disables the write tools entirely at the server level, rather than relying only on the Gramps Web account’s permissions, and also saves tokens, since the model never even sees schemas for tools it can’t call.
There’s also dsblank/gramps-ez-mcp, which takes a different route: talking to the Gramps database directly instead of going through Gramps Web.
Would be glad for feedback from anyone running Gramps Web, especially if you hit API behavior that seems off when driven this way rather than through the normal UI. That’s where most of the interesting edge cases have shown up so far.