There is an increasing number of clients that talk to Gramps Web API, most of them AI-related, especially MCP servers. It’s nice that Gramps Web API’s open architecture allows users to try out these tools and interact with their tree in different ways.
Apart from maintaing Gramps Web API, I’m also running the Grampshub hosting service. Grampshub puts privacy first, so any sort of logging is reduced to the bare minimum. However, there two things I need to monitor to ensure the service is actually running:
- Server load including number of requests by user-agent (which is a string identifying which browser or other application made the HTTP request)
- Server errors raised by Gramps Web API (which do not contain tree or other personally identifiable data, but the traceback of the error in Gramps Web API).
What I’ve observed over the last months is that
- The number of requests from AI agents (e.g. Claude) has increased. Claude is nice enough to identify itself via a user-agent string
- The number of requests from scripts not identifying themselves has increased (just using the httpx or node default user-agents)
- The number of server errors has drastically increased, and most of the time they clearly come from AI, as the type of request does not exist in any of the existing frontends
If you followed the last few release notes of Gramps Web API, you will have seen a lot of
- Improved error handling
- Improved endpoint documentation
These changes are designed to reduce the likelihood and the blast radius of incorrect edits by AI agents.
To be clear: there is no plan to restrict the use of AI agents either in Gramps Web API or on Grampshub.
However, there is one thing I’d like to ask of all maintainers of such clients: please make sure your tool identifies itself with a User-Agent string including tool name and version.
Why?
Because it will allow Gramps Web API server administrators to identify for each server error which tool caused it and report it upstream in the tool’s repository.
It will also allow the Gramps Web API project to identify problematic patterns and suggest changes to a tool or implement changes in Web API itself.
Thanks for your consideration!
