While investigating #48 I confirmed that update_page already routes page properties through logseq.Editor.setPageProperties (since 5b99215, shipped in v1.6.2). On DB graphs this updates page-level properties as expected. On file-based graphs Logseq appends the properties as a new block at the end of the page instead of updating the key:: value header lines. The properties never reach Logseq's property system, while the tool reports success.
I'm not going to patch around this in mcp-logseq. Switching to upsertBlockProperty unconditionally would regress DB mode (that is what 5b99215 fixed, see also the review on PR #49). This issue tracks the upstream behavior so it can be revisited when Logseq fixes it.
Notes:
Related: #48, PR #49
While investigating #48 I confirmed that
update_pagealready routes page properties throughlogseq.Editor.setPageProperties(since 5b99215, shipped in v1.6.2). On DB graphs this updates page-level properties as expected. On file-based graphs Logseq appends the properties as a new block at the end of the page instead of updating thekey:: valueheader lines. The properties never reach Logseq's property system, while the tool reports success.I'm not going to patch around this in mcp-logseq. Switching to
upsertBlockPropertyunconditionally would regress DB mode (that is what 5b99215 fixed, see also the review on PR #49). This issue tracks the upstream behavior so it can be revisited when Logseq fixes it.Notes:
setPagePropertiesdoesn't appear in the@logseq/libsIEditorProxydocumentation, so it may be an unstable or undocumented API.update_pagewithpropertieson file-based graphs. DB graphs are fine.update_pagewithproperties-only appends properties as body block instead of updating page-level properties in place #48 (tags:: ['mcp-test']Python repr) was a real bug in this codebase's parser and is fixed separately.Related: #48, PR #49