Observed on main @ 67791060 (server/index.ts), during end-to-end testing of a live deployment.
What happens
search_thoughts and list_thoughts format their results without the row id:
search_thoughts renders --- Result N (X% match) ---, captured date, type, topics, people, actions, and content — but no id. (match_thoughts already returns id; it just isn't printed.)list_thoughts renders N. [date] (type - topics)\n content — no id, and its .select("content, metadata, created_at") doesn't even fetch the id.
The only read tool that returns ids is search (the ChatGPT/connector-compat tool returning { id, title, url }), and fetch requires an id.
Why it matters
update_thought and delete_thought require a UUID. A user working through the primary human-facing read tools can see a thought but cannot obtain its id to update or delete it — they must detour through the search compatibility tool, which returns a terser shape intended for ChatGPT connectors. The natural "find it → change/remove it" flow is broken for the main read tools.
Suggested fix
Include the id in both tools' output — a leading id: <uuid> line per result, or a structured field. search_thoughts already has t.id from match_thoughts; list_thoughts just needs id added to its .select(...).
Same underlying theme as the capture_thought "return the id" gap: the write/mutate tools need UUIDs that the read tools don't expose.
Observed on
main@67791060(server/index.ts), during end-to-end testing of a live deployment.What happens
search_thoughtsandlist_thoughtsformat their results without the rowid:search_thoughtsrenders--- Result N (X% match) ---, captured date, type, topics, people, actions, and content — but no id. (match_thoughtsalready returnsid; it just isn't printed.)list_thoughtsrendersN. [date] (type - topics)\n content— no id, and its.select("content, metadata, created_at")doesn't even fetch the id.The only read tool that returns ids is
search(the ChatGPT/connector-compat tool returning{ id, title, url }), andfetchrequires an id.Why it matters
update_thoughtanddelete_thoughtrequire a UUID. A user working through the primary human-facing read tools can see a thought but cannot obtain its id to update or delete it — they must detour through thesearchcompatibility tool, which returns a terser shape intended for ChatGPT connectors. The natural "find it → change/remove it" flow is broken for the main read tools.Suggested fix
Include the id in both tools' output — a leading
id: <uuid>line per result, or a structured field.search_thoughtsalready hast.idfrommatch_thoughts;list_thoughtsjust needsidadded to its.select(...).Same underlying theme as the
capture_thought"return the id" gap: the write/mutate tools need UUIDs that the read tools don't expose.