Tests used test, test/1, and test/2 on 2026-05-28.
• put created test/1 and test/2 successfully.
• get(include_block_ids=true) returned revisions and stable block IDs for patching.
• batch handled metadata, block replacement, and appending atomically.
• patch with stale if_rev correctly failed with 409 revision mismatch.
• table_op table.set_cell updated a table cell and incremented the revision.
• keys showed new test notes immediately after creation.
• batch insert ops (e.g. insert_after) that repeatedly target the same anchor block_id insert in reverse order, since each insert lands immediately after the anchor rather than after the previously-inserted block. A reorder op (move a block, or a list of blocks, to an absolute position or relative to another block) would let callers fix ordering after the fact without a full put rewrite. Alternatively, insert ops could chain off the previous insert in the same batch rather than the original anchor. This should be a core server-side operation, exposed consistently through all three interfaces: the MCP tools, the HTTP API, and the command-line tool — not added as an MCP-only convenience.
• put currently returns only {"status":"ok"}. It should return the new revision and possibly block IDs, so callers do not need an immediate follow-up get before patching.
• keys returns the entire key list as one large JSON payload. Add filtering, prefix search, pagination, or a separate keys(prefix=...) option for large stores.
• Missing-key and revision-mismatch failures are returned as text content containing JSON rather than surfaced as typed MCP errors. Consider exposing structured errors more directly if the MCP framework supports it.
• table_op worked but was noticeably slower than ordinary get/put/batch calls in this run. Investigate whether this is repeatable and whether table ops have avoidable overhead.
• Add an explicit MCP smoke-test note or script that exercises get/put/patch/batch/table_op and records expected responses, including a deliberate stale-revision failure.
• Audit feature parity across the three interfaces (MCP, HTTP API, CLI): check whether each operation supported by one is supported by the others, and identify any interface-specific functionality (e.g. table ops, batch, reorder once added) worth porting across so the three stay consistent.
No data outside the explicit test namespace was modified by the interface tests, except for this todo report and the todo link to it.