Origin: ChatGPT review on 2026-06-29 after reading the notes bootstrap key, README, TRIGGERS, MEMORY, README/agent, and the existing todo/improvement notes.
Purpose: collect improvement suggestions that appeared not to be documented already, or only indirectly documented, so they can be worked through later without relying on the chat transcript.
• MCP success-response shape consistency — During the review, get("README") returned a parsed result, but keys() and get(..., include_block_ids=true) returned a text field containing stringified JSON. This is awkward for agents and increases parsing risk. Existing todo notes mention text-wrapped errors, but this exact success-response inconsistency should be recorded and investigated.
• Update README/mcp-tools to list all seven MCP tools — The document lists keys, get, put, patch, batch, and table_op, but omits delete. mcp-interface-improvements already records that the current MCP tool set is seven tools, so the main MCP documentation is drifting.
• Generated or verified MCP capability summary — Consider a generated note or smoke-test output that records the current MCP manifest and expected response shapes. This would catch drift between server implementation, connector registration, documentation, and what ChatGPT/Claude actually see. It complements the existing MCP smoke-test idea but should explicitly include manifest/capability verification.
• Clean up structural oddities in existing docs/todos — Several notes look internally mis-sectioned or duplicated: README repeats Quick Rules-style material under Runnable Documents; README/orphaning places the Index Pages section in the middle of metadata preservation; gdata-server/todo has a Private notes instance item under Completed although it reads as open; notes-browser/todo has Cell output scroll control via API under Completed although it reads as a todo.
• Todo/status schema for todo notes — Free-text todo notes make it easy for open work to appear under Completed or for status to be ambiguous. Consider a convention for todo items with fields such as status (open/done/deferred), priority, owner, target date, and needs-John-decision. This relates to, but is broader than, the existing interactive-checkbox idea in notes-browser/todo.
• Split workflow documentation by interface — README/workflow is mostly CLI-first, using notes read / local JSON file / notes load -d. That remains correct for CLI work, but MCP/agent editing is now important enough that the workflow page should explicitly branch into CLI workflow versus MCP/agent workflow, linking to README/mcp-tools and the safe-edit strategy notes.
1. Fix or document the MCP success-response shape inconsistency, because it directly affects agent reliability.
2. Update README/mcp-tools to include delete and clarify the current seven-tool set.
3. Add a manifest/check output to the MCP smoke test so documentation drift is caught automatically.
4. Clean the mis-sectioned documentation/todo entries as a separate content-maintenance pass.
• gdata-server/todo — parent todo list for gdata-server and notes-system improvements.
• gdata-server/todo/mcp-interface-improvements — existing MCP interface findings and improvement list.
• gdata-server/todo/jsonhtl-documentation-improvements — JSONHTL documentation and linter gaps.
• README/mcp-tools — current MCP workflow/tool documentation.
• README/workflow and README/orphaning — broader note creation and maintenance rules.