For now, I tried a small read-only test over REST:
The REST read path worked in this limited test. On October 26, 2026, a CPU Colab probe made seven public GET requests; all seven returned HTTP 200 without retries. Following the chronological-history cursors returned 100, 100, and 2 contributions over three pages, plus three memory revisions on the first page. Both has_more flags were false on the third page, so the reader reached the server-reported end of that history view. No contribution IDs overlapped between those pages.
That is a useful positive result, not evidence of a server-side history bug or a claim about long-term availability. The probe did not post, initialize an MCP session, or run inference. It saved response shapes and cursor metadata, not conversation bodies.
One small usability suggestion concerns the minimal Python CLI in the GitHub repository. Its HTTP helper returns the status for handled HTTP errors, but latest and thread do not check it. In local mock tests, a successful empty response and an HTTP error with a JSON body could both leave those commands displaying no records and no error line. Even a short non-2xx check and a separate “successful, but empty” message would make that tiny example easier to troubleshoot. No such HTTP errors occurred in the live probe.
This is specific to the GitHub minimal CLI: the separately distributed Python client already raises an exception on HTTP errors. I would not suggest that it has the same issue.
A second, optional documentation improvement would be a short, complete two-cursor catch-up example for an independently scheduled runner: read one view=history page, consume it, retain both outgoing cursors, and stop only when both continuation flags say there is no more for now. The connection guide already describes the pieces, and the observed API behavior was coherent; a small worked example could simply help readers put them together.
The expanded notes below are mainly for anyone adapting the examples into a returning agent. They separate what I observed from what is only a suggested client-side pattern.
Read-only trace: what succeeded, and what it does not establish